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EXECUTIVE  SUMMARY 


The  overall  objective  of  the  Department  of  Defense  Computer-aided 
Acquisition  and  Logistic  Support  (CALS)  Program  is  to  integrate  the 
design,  manufacturing,  and  logistic  functions  through  the  efficient 
application  of  computer  technology.  NIST  has  been  funded  since 
Spring  1986  to  recommend  a  suite  of  industry  standards  for  system 
integration  and  digital  data  transfer,  and  to  accelerate  their 
implementation . 

During  FY86  NIST  tasks  for  CALS  in  the  area  of  graphics  standards 
focused  on  identification  of  recommended  standards  to  OSD  which 
would  be  applicable  to  the  DoD  environment;  comparison  of  graphics 
standards  among  themselves  and  with  product  data  standards;  and  the 
status  of  ongoing  graphics  standards  efforts  as  well  as  related 
validation  efforts  .  CALS'  needs  for  graphics  standards  were 
assessed,  and  an  architecture  for  their  inclusion  into  specific 
CALS  programs  was  created.  Finally,  a  plan  was  recommended  for 
accelerating  the  development,  related  validation  efforts  and 
implementation  of  graphics  standards  into  the  CALS  program. 

Building  on  the  knowledge  and  experience  gained  during  FY86,  NIST 
tasks  for  CALS  in  the  area  of  graphics  standards  in  FY87  emphasized 
the  particular  graphics  standard  dealing  with  the  transfer  of 
pictorial  data  from  one  system  to  another,  namely  the  Computer 
Graphics  Metafile  (CGM)  standard  (FIPS  PUB  128)^.  Graphics  tasks 
included  an  assessment  of  raster-to-vector  conversion  technology, 
and  where  the  CGM  might  fit  into  that  process;  efforts  toward 
development  of  CGM  validation  routines;  injection  of  CALS 
requirements  into  the  Extended  CGM  (CGEM)  standards  work,  as  well 
as  into  the  CGM  Registration  process.  In  addition,  functional 
requirements  and  conceptual  design  documents  were  completed  for  a 
reference  implementation  for  CGM;  a  design  specification  was 
created  for  an  IGES-to-CGM  translator;  and  a  preliminary  CALS 
Application  Profile  for  CGM  was  formed  from  the  application  profile 
work  of  the  MAP/TOP  organization. 

During  FY88,  NIST  tasks  for  CALS  in  the  graphics  standards  area 
were  in  large  measure  a  continuation  of  those  efforts  begun  the 


^Kemmerer,  S.,  Editor,  "Final  NBS  Report  for  CALS,  FY86,"  U.S. 
Department  of  Commerce,  National  Bureau  of  Standards,  NBSIR  87- 
3566,  May  1987. 

^Kemmerer,  S.,  Editor,  "A  Collection  of  Technical  Studies 
Completed  for  the  Computer-aided  Acquisition  and  Logistic  Support 
(CALS)  Program,  Fiscal  Year  1987,"  U.S.  Department  of  Commerce, 
National  Bureau  of  Standards,  NBSIR  88-3727,  March  1988. 
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year  before^.  Final  text  was  completed  for  the  initial  publication 
of  a  Military  Specification  which  is  the  CALS  Application  Profile 
for  CGM.  NIST  continued  to  participate  in  graphics  standards  work 
in  support  of  CALS  requirements  in  the  areas  of  CGM  conformance 
testing,  the  CGEM,  and  CGM  Registration.  In  the  particular  area 
of  CGM  conformance  testing,  the  needs  for  testing  both  to  FIPS  128 
and  to  the  Application  Profile  for  CGM  were  identified;  existing 
commercial  implementations  of  CGM  were  analyzed  and  compared 
functionally  to  both  CGM  and  Application  Profile  requirements;  and 
required  CGM  conformance  testing  tasks  were  described  in  detail, 
responsibilities  in  the  testing  process  delineated,  and  the  impact 
of  CGM  testing  was  assessed  both  for  CALS  and  the  commercial 
marketplace. 

This  collection  of  reports  represents  the  continuing  efforts  of 
the  Graphics  Software  Group  of  NIST/NCSL  in  FY89  in  support  of 
computer  graphics  standards  for  CALS,  and  in  particular  CGM^.  It 
provides  a  progress  report  on  continuing  graphics  standards  efforts 
related  to  the  Computer  Graphics  Metafile  (CGM)  standard,  including 
the  Extended  CGM  (CGEM) ,  Graphics  Registration,  and  the  CGM 
Application  Profile  for  CALS  (or  MIL-D-28003) .  In  addition,  the 
creation  of  a  Test  Requirements  Document  for  MIL-D-28003  is 
detailed.  This  Test  Requirements  Document  will  provide  the  basis 
for  developing  conformance  tests  to  determine  compliance  with  MIL- 
D-28003. 

This  report  is  subdivided  into  four  separate  final  CALS 
deliverables,  entitled  as  follows: 

1.  Test  Requirements  Document  for  CALS  CGM  Conforming  Basic 
Metafiles 

2.  Injection  of  CALS  Requirements  in  the  Extended  CGM  (CGEM) 
Standards  Work 

3.  MIL-D-28003  Revision  Recommendations 

4.  CGM  Registration  in  Support  of  CALS  Requirements 


^Morgan,  Roy  S.,  Editor,  ”A  Collection  of  Technical  Studies 
Completed  for  the  Computer-aided  Acquisition  and  Logistic  Support 
(CALS)  Program,  Fiscal  Year  1988,  U.S.  Department  of  Commerce, 
National  Institute  of  Standards  and  Technology,  NISTIR  4315,  4316, 
and  4317. 

^The  publishing  of  this  collection  of  reports  does  not  imply 
that  the  CALS  Office  has  endorsed  the  conclusions  or 
recommendations  presented. 


iv 


An  additional  deliverable  completed  for  CALS  by  the  Graphics 
Software  Group  during  FY89  detailed  the  impact  that  two  other 
graphics  standards  (namely  PHIGS,  or  the  Programmers  Hierarchical 
Interactive  Graphics  System,  and  PIK,  or  the  Programming  Imaging 
Kernel)®  will  have  on  the  CALS  environment.  It  was  published  under 
separate  cover,  and  is  available  through  the  CALS  Policy  Office  or 
through  the  National  Technical  Information  Service. 


®Kemmerer,  Sharon  J.,  and  Skall,  Mark  W. ,  "Graphics 
Application  Programmer's  Interface  Standards  and  CALS,"  U.S. 
Department  of  Commerce,  National  Institute  of  Standards  and 
Technology,  NISTIR  89-4199,  October  1989. 
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1.  Sumnary  &  Recommendations 
1 . 1  Overview 

This  report  describes  activities  during  FY89,  presents  final 
recommendations,  and  recommends  future  work  for  updating  the  CALS 
Application  Profile  (AP)  of  CGM,  MIL-D-28003  (CAL  SOW  Task 
4.1.2)  . 

This  task  has  consisted  of  two  subtasks: 

A.  Reconciliation  of  the  CALS  and  TOP  APs  of  CGM. 

B.  Recommendations  for  modifications  and  extensions  of  the 
CALS  AP. 

Subtask  A  has  resulted  in  substantial  agreement  between  CALS  and 
MAP/TOP  technical  personnel  and  is  at  a  point  where 
administrative  action  is  required  by  both  sides  to  create  and 
execute  the  mechanisms  for  consolidating  the  projects.  Further 
attention  on  this  subtask  is  needed  in  FY90  to  bring  about  a 
consolidation  of  the  separate  industry  and  government  efforts. 

Subtask  B  has  resulted  in  a  substantial  body  of  recommendations 
for  amendments  to  MIL-D-28003.  These  recommendations  are 
detailed  in  the  body  of  this  report.  There  is  also  a  plan  for 
the  updates  to  MIL-D-28003  which  addresses: 

o  timing,  including  coordination  with  activities  in 
graphics  standards; 

o  body  of  content  to  be  included; 

o  mechanics  and  procedures  of  producing  the  new 
MIL-D-28003. 

Some  of  the  content  of  the  MIL-D-28003  revision  is  being 
sponsored  in  Graphical  Registration.  Close  liaison  with  the 
proposers  has  been  maintained. 

Finally,  the  recommendations  in  this  report  are  not  complete 
because: 

o  Some  content  is  pending  completion  of  actions  in 
graphics  standards  committees  -  these  will  be 
relatively  routine. 

Other  content  has  been  specified  at  a  conceptual  level 
but  requires  detailed  formulation  -  these  are  items 
which  derived  from  NIST/NCSL  requirements  studies 
produced  late  in  FY89. 
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o  The  work  of  this  fiscal  year  has  identified  a  body  of 
changes  larger  than  anticipated  and  resources  were 
therefore  not  sufficient  to  cover  all  needed  work. 

This  subtask  will  require  additional  work  to  produce  the  final 
text  for  revised  MIL-D-28003  in  FY90. 

Because  of  slower  than  expected  progress  of  needed  CALS 
extensions  in  both  the  formal  standards  (the  CGM  addenda)  and 
graphical  registration,  the  criteria  for  inclusion  of  some 
extensions  into  the  MIL-D-28003  revision  have  been  changed.  The 
new  criteria  insure  adequate  US  national  review  but  do  not 
require  the  formal  completion  of  the  standards  or  registration 
process. 

The  extensions  and  additions  proposed  in  the  recommendations  of 
this  report  derive  from  and  logically  follow  events  in  the 
graphics  standards  committees.  In  this  report  the  issues  of 
procedures  and  timing  for  amending  MIL-D-28003  have  been 
investigated,  and  NIST/NCSL  concludes  that  the  most  effective 
procedure  will  be  one  where  the  MIL-D-28003  review  and  amendment 
process  can  start  at  a  time  that  is  linked  to  milestones  in  the 
graphics  standards  process. 


2.  Reconciliation  of  the  TOP  and  CALS  Profiles 

One  of  the  goals  of  the  Profile  work  from  the  beginning  was  a 
reconciliation  of  the  differences  between  the  TOP  and  CALS 
profiles. 

The  TOP  CGM  Application  Profile  was  the  starting  point  for  the 
CALS  profile.  The  NIST/NCSL  representative  participated  in  the 
review  and  refinement  of  the  TOP  profile  until  its  completion  in 
1988.  The  CALS  profile  then  had  more  than  6  months  of  additional 
review  and  refinement.  As  a  result  there  are  a  number  of 
discrepancies  between  the  two  profiles.  Some  of  these  are  due  to 
extensions  and  additional  specifications  in  the  CALS  profile, 
such  as  additional  engineering  line  types  and  hatch  styles. 

It  has  always  been  a  goal  of  this  project  to  keep  the  TOP  and 
CALS  profiles  identical  where  they  overlap.  The  proliferation  of 
similar  but  slightly  different  "dialects”  of  CGM  would  cause 
confusion  in  the  industry  and  should  be  avoided.  The  TOP  and 
CALS  constituencies  are  considered  to  be  sufficiently  similar 
that  they  might  use  the  same  profile,  or  at  least  use  subsets  of 
a  single  profile. 
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To  explore  this  possibility  the  NIST/NCSL  representative  met  with 
the  TOP  CGM  expert  and  editor  of  the  TOP  profile,  Mr.  Kern 
Hardman.  This  meeting  took  place  at  the  National  Computer 
Graphics  Association  exposition  in  Philadelphia  in  late  April 
1989.  After  some  discussion  it  was  agreed  that  it  was  desirable 
to  fold  the  TOP  and  CALS  profiles  into  a  single  specification, 
perhaps  with  a  separate  TOP  document  pointing  to  the  single 
specification  and  defining  a  subset. 

As  an  aid  in  evaluating  whether  to  pursue  this  merger,  and  as  a 
necessary  first  step  in  defining  the  TOP  document,  a  study  of  the 
differences  between  the  two  profiles  was  produced.  This  was  sent 
to  Mr.  Hardman  in  early  August.  The  study  and  cover  letter  to 
Mr.  Hardman  are  in  Attachment  1  of  this  report. 

There  has  been  subsequent  communication  with  Mr.  Hardman.  The 
consolidation  of  effort  is  agreeable  in  principle  to  both 
parties.  The  preliminary  technical  content  of  the  first 
MIL-D-28003  revision,  as  detailed  in  this  report,  is  generally 
agreeable  to  Mr.  Hardman.  There  are  a  number  of  procedural 
issues  which  must  be  resolved.  The  Information  Technology 
Requirements  Council  (ITRC)  of  MAP/TOP  has  stated  its  position 
that  the  efforts  of  industry  and  government  should  be  merged,  and 
detailed  its  concerns  over  procedure,  in  a  letter  to  the  Director 
of  the  CALS  office.  Dr.  Michael  McGrath.  This  letter  is 
contained  in  Attachment  2  to  this  report.  Further  action  at  the 
technical  experts  level  is  not  likely  to  be  effective  until 
administrative  arrangements  are  agreed. 


3.  CALS  Profile  Revision 

What  follows  is  a  discussion  of  the  activities  during  FY89  for 
the  task  of  defining  the  next  revision  of  the  CALS  profile. 
Criteria  used  to  guide  the  selection  of  additions  and  changes  to 
the  profile  will  be  presented.  Finally  all  of  the  recommended 
functionality  will  be  listed,  indicating  its  status,  and 
indicating  what  further  actions  are  required  before  draft  text 
can  be  produced. 

During  FY89  some  procedural  and  timing  questions  were  opened  and 
resolved,  and  they  will  be  discussed  as  well. 


3 . 1  Activities 

The  following  work  has  been  done  to  prepare  the  recommendations 
for  revision  of  MIL-D-28003. 
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1.  Assessed  the  31  functions  of  CGM  Addendum  1  for  importance 
to  CALS  graphical  interchange  and  produced  sorting  by 
inclusion  or  exclusion. 

2 .  Contacted  X3H3  registration  experts  at  NIST/NCSL  to 
determine  the  status  and  expected  timetable  of  all  of  the 
CALS  registration  proposals  currently  in  progress;  verified 
and  discussed  US  positions  on  these  proposals  in  the  ISO 
bodies. 

3.  Reviewed  past  and  current  CALS  requirements  studies. 

4.  Contacted  NIST/NCSL  CALS  liaison  to  ascertain  and  decide 

policies,  procedures,  requirements,  and  timetables  for  the 
amendment  process  for  MIL-D-28003. 

5.  Contacted  NIST/NCSL  CALS  liaison  and  members  of  the  CALS 

Industry  Standards  Working  Group  to  attempt  to  ascertain 
what  implications,  if  any,  a  pending  1840A  "presentation 
problem"  has  for  MIL-D-28003. 

6.  Correlated  all  potential  extension  items  and  modification 

suggestions  with  requirements  and  feasible  timetables  to 
produce  the  set  of  recommendations  in  this  report. 

7.  Prepared  interim  report  with  preliminary  recommendations, 
and  circulated  this  report  for  comment  within  the  CALS, 
graphics  standards,  and  MAP/TOp  communities. 

8.  Prepared  this  final  report. 


3 . 2  References 

In  the  remainder  of  this  report  a  few  key  documents  are  referred 

to: 

1.  CGM  Addendum  1:  the  first  set  of  formal  standard  extensions 
of  CGM;  recently  completed  substantive  ISO  processing;  final 
text  should  be  available  near  the  end  of  the  year  or  early 
in  1990. 

2.  Registration  Proposals:  exist  in  various  X3H3  documents;  are 
contained  in  the  final  report  titled  FINAL  REPORT,  CALS  FY89 
SOW  TASK  4.3.4,  CALS  REQUIREMENTS  FOR  CGM. 
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3.3  Procedural  Considerations 

The  content  of  the  first  revision  to  MIL-D-28003  depends  to  some 
extent  upon  the  procedure  by  which  the  amendment  is  made,  and 
upon  the  anticipated  frequency  of  amendments.  Because  the 
functionality  of  the  amendment  is  taken  from  work  already 
completed  or  work  in  progress  within  the  graphics  standards 
bodies,  the  amendment  procedure  must  be  coordinated  and 
correlated  with  certain  milestones  in  the  graphics  standards 
bodies.  The  ideal  timing  of  the  amendments  should  be; 

batch  of  functionality  reaches  sufficiently  stable  milestone 
in  graphics  standards  and  registration  processes; 

CALS  required  functionality  extracted  and  included  in 
proposed  amendment; 

DoD,  services,  and  industry  review  commences. 

The  extensions  ideally  are  driven  by  the  progress  of  needed  items 
through  the  graphics  standards  process. 

At  the  start  of  FY89  it  was  not  known  whether  this  method  of 
proceeding  would  be  acceptable  within  the  established  review  and 
amendment  procedures,  or  fit  the  goals  and  timetable  of  the  CALS 
program.  In  particular  the  following  information  was  needed 
before  defining  what  the  scope  of  the  amendments  should  be. 

1.  How  is  MIL-D-28003  amended?  What  are  the  procedures  and 
milestones  in  the  process,  and  who  are  the  key  organizations 
and  individuals? 

2.  How  long  is  the  process  anticipated  to  take  from 
commencement  to  conclusion? 

3.  Does  CALS  have  a  firm  schedule  for  when  the  first  set  of 
amendments  should  be  processed? 

4.  Is  there  a  regularly  scheduled  amendment  cycle,  for  example 
every  year  or  every  two  years? 

5.  If  not  does  CALS  then  have  any  requirements,  guidelines,  or 
criteria  for  minimum  or  maximum  time  between  amendments  or 
extensions? 

6.  Does  Version  2  of  MIL-D-28003  supersede  Version  1  at  some 
point  in  time,  or  do  Version  2  and  Version  1  both  exist  as 
legitimate  interchange  indefinitely?  If  the  former,  is 
there  a  period  of  overlap  where  both  are  acceptable  or  does 
Version  l  become  obsolete  and  Version  2  operational  on  some 
definite  fixed  date? 
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7.  Is  there  a  requirement  for  backwards  compatibility  of  the 
profile,  implying  for  example  that  there  can  be  no  deletions 
from  Version  1? 

These  issues  were  presented  and  discussed  with  the  NIST/NCSL  CALS 

liaison.  Further  discussion  within  NIST/NCSL  and  with  the 

Services  have  resulted  in  these  conclusions: 

1.  The  MIL-D-28003  revision  schedule  will  be  coordinated  with 
certain  key  milestones  in  the  graphics  standards  and 
registration  process  over  the  next  fiscal  year,  FY90. 

2.  The  magnitude  of  the  changes  to  the  profile  will  classify  it 
as  a  revision,  and  the  resulting  profile  will  have  a  new 
designation  of  MIL-D-28003A. 

3.  The  requirement  for  backwards  compatibility  is  not  clear. 
However  the  desirability  of  such  is  clear  and  changes  which 
create  an  incompatibility  between  the  current  and  revised 
profile  will  be  considered  carefully. 

4.  There  should  minimally  be  two  years  between  substantive 
revisions  to  the  profile. 


3.4  Criteria  for  Inclusion 

There  is  a  large  number  of  potential  extensions  that  are  now  or 
within  6  months  will  be  at  a  sufficiently  stable  point  in  the 
standards  and  registration  pipeline.  In  selecting  those  changes 
to  go  into  the  first  revision  of  MIL-D-28003  NIST/NCSL  has 
attempted  to  balance  a  number  of  sometimes  conflicting  criteria 
and  guidelines. 

Firstly,  the  proposal  must  be  fairly  stable.  Ideally  everything 
in  the  profile  would  be  a  part  of  the  CGM  standard  or  a  completed 
standard  extension.  The  delays  in  that  process,  particularly  CGM 
Addendum  3,  may  make  this  level  of  stability  impractical.  A 
timeliness  requirement  may  force  inclusion  of  features  ahead  of 
their  formal  inclusion  in  the  standard.  If  this  is  the  case, 
then  NIST/NCSL  thinks  that  industry  could  tolerate  the  extensions 
being  included  in  a  preliminary  formulation  that  is 
architecturally  and  functionally  similar  to  what  is  expected  to 
appear  in  the  formal  CGM  extensions. 

The  implications  to  implementations  of  the  profile  leading  the 
formal  standards  are  as  follows.  Implementations  would  have  to 
make  an  investment  in  new  basic  technology  now.  If  the  profile 
were  amended  again  in  a  couple  years  when  a  piece  of 
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functionality  had  completed  formal  processing  and  had  become  part 
of  the  CGM  standard,  then  an  implementation  would  have  to  revise 
mostly  the  interface  to  the  piece  of  basic  technology.  What  this 
means  is  that  the  parameterization  or  precise  structure  of  the 
particular  functionality  would  change  in  the  final  version,  and 
would  require  some  modification  to  the  metafile  encoder  or 
decoder  of  the  implementation.  This  would  be  a  minor  effort 
relative  to  the  initial  effort  to  implement  the  basic  technology, 
since  the  major  part  of  the  implementation  effort  is  devising  and 
including  the  basic  technology. 

While  it  would  be  preferable  to  have  no  changes  in  the  future  to 
extensions  being  currently  included,  NIST/NCSL  feels  for  any 
given  functional  extension  that  one  change  of  such  a  nature  will 
be  acceptable.  NIST/NCSL  does  not  think  that  two  changes  would 
be;  it  will  create  too  much  confusion  in  the  industry.  This 
could  happen  for  example  if  a  GDP  (Generalized  Drawing  Primitive) 
were  included  as  a  private  GDP  in  MIL-D-28003,  and  then  a  changed 
formulation  completed  graphical  registration  and  were  adopted  in 
an  amendment,  and  then  yet  another  different  formulation  were 
included  in  the  formal  CGM  extensions  that  comprise  Addendum  3 
and  adopted  in  a  second  amendment. 

With  these  principles  in  mind,  almost  all  of  the  functionality 
which  NIST/NCSL  recommends  for  MIL-D-28003A  is: 

1.  In  the  CGM  standard  or  the  first  standard  extension,  CGM 
Addendum  1 ;  or 

2.  will  be  in  CGM  Addendum  3  in  some  form;  or 

3 .  Has  completed  Graphical  Registration  or  has  reached  a 
"stable”  milestone  in  Graphical  Registration. 

Concerning  the  second  and  third  points,  note  that  a  number  of  CGM 
extensions  identified  in  CALS  requirements  studies  are  being 
promoted  through  the  standards  and  registration  process  as  part 
NIST/NCSL 's  work  on  CALS. 

The  qualifier  "almost  all"  needs  explanation.  Some  features  that 
were  included  in  MIL-D-28003,  in  particular  a  few  of  the  hatch 
styles,  have  been  rejected  by  the  Graphical  Registration 
Authority  in  its  first  consideration  (all  of  the  rest  of  the  line 
types  and  hatch  styles  were  approved) .  A  narrow  view  of  what 
comprises  a  "hatch"  was  taken,  and  NIST/NCSL  thinks  the  decision 
will  be  reversed.  But  in  any  case,  the  styles  were  identified  in 
CALS  requirements  studies,  and  if  the  ISO  committees  refuse  the 
proposals  then  they  should  stay  in  the  profile  as  private  types 
and  values. 
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The  definition  of  "stable”  as  it  is  used  above  needs  definition. 
Ultimately  no  proposal  is  stable  until  it  is  approved  by  the 
relevant  ISO  body  and  is  "on  the  books."  The  US  position  on 
registration  is  that  the  ISO  Graphical  Registration  Authority 
should  only  reject  or  modify  a  proposal  if  it  is  flawed, 
incorrect,  or  unworkable.  By  this  principle,  once  the  US  takes 
the  proposal  out  of  X3H3  (the  domestic  graphics  standards 
committee)  to  ISO  it  should  then  be  stable.  This  is  the 
criterion  NIST/NCSL  will  apply  for  inclusion  of  registration 
proposals  in  the  amended  MIL-D-28003.  The  US  procedures 
generally  result  in  two  rounds  of  review  in  X3H3 .  This  should 
take  a  year  or  less  (but  its  timeliness  is  dependent  upon 
continuity  of  efforts  to  "shepherd"  the  proposals  once  they  are 
formulated) . 

In  selecting  this  definition  the  alternatives  were  considered. 
There  are  two  earlier  milestones  that  could  potentially  be  chosen 
as  the  inclusion  milestone  for  CALS  extensions; 

the  initial  formulation  of  the  proposal  itself; 

the  end  of  the  first  round  of  review  within  X3H3. 

NIST/NCSL  thinks  both  of  these  are  inadvisable  and  likely  to 
introduce  errors  and  incompatibilities  into  the  profile.  This  is 
no  reflection  upon  the  talent  of  the  proposer  or  the  quality  of 
that  work.  Rather  the  current  set  of  graphics  standards  and 
related  specifications  is  so  broad  and  so  interwoven  and 
interrelated  that  review  by  experts  and  specialists  in  all  of  the 
disciplines  of  X3H3  is  necessary  in  order  to  assure  that  the 
proposal  is  both  correct  and  consistent  with  related  work. 
NIST/NCSL  therefore  recommends  the  inclusion  guideline: 

Recommendation:  a  proposed  functional  extension  is  stable 
enough  for  inclusion  in  MIL-D-28003  if  either  the  item  is  a 
registration  proposal  with  two  rounds  of  review  in  X3H3 ,  or  the 
item  is  in  the  final  text  of  CGM  or  one  of  its  addenda,  or  the 
item  has  completed  the  registration  process  in  ISO. 

While  NIST/NCSL  does  not  preclude  the  inclusion  of  something  less 
stable,  the  requirement  should  be  compelling  if  this  is 
considered. 

MIL-D-28003A  will  contain  additions  to  MIL-D-28003  and  may  also 
delete  some  specifications  or  alter  some  specifications. 
NIST/NCSL  believes  that  backward  compatibility  is  a  strong  goal 
(if  not  a  requirement,  see  previous  section)  and  so  deletions  and 
changes  are  approached  with  some  caution.  There  is  no  question 
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If  there  is  a  mistake  or  defect  to  be  fixed.  Other  cases  must  be 
approached  on  a  case-by-case  basis.  If  a  specification  is  not 
being  used  or  implemented,  then  there  is  little  problem  with 
deleting  or  changing  it.  If  it  is  in  use  then  the  justification 
for  change  should  be  strong. 

One  final  criterion  which  deserves  some  discussion  is  timing  of 
amendments  and  changes.  There  are  two  aspects  to  this  issue: 
when  should  the  first  amendment  begin  review;  and  how  often 
should  major  amendments  be  anticipated.  NIST/NCSL  recommends 
that: 

Recommendation:  the  first  amendment  should  commence  review 
after  final  text  of  CGM  Addendum  1  is  produced,  and  after  the 
second  batch  of  registration  proposals  completes  its  second  X3H3 
review  (see  below) . 

Recommendation:  a  major  upgrade  about  every  two  years  is 
acceptable;  more  frec[uently  would  be  too  demanding  on  the 
industry . 


3.5  Addendum  1:  Status  &  Recommendations 

The  first  formal  standard  extension  to  CGM,  Addendum  1,  completed 
its  final  ISO  ballot  in  June.  Preliminary  final  text  has  been 
produced  and  is  being  reviewed  for  accuracy  for  6  weeks.  Early 
indications  are  that  a  second  6-week  review  will  be  required, 
commencing  sometime  in  November.  Final  text  should  be  available 
by  Januairy  1990. 

There  are  two  basic  pieces  of  functionality  in  CGM  Addendum  1 
that  CALS  has  been  interested  in  and  has  been  promoting: 

o  Global  Segments:  this  is  an  internal  symbol  definition  and 
instancing  capability.  This  was  identified  as  a  high 
priority  item  in  FY87  CALS  requirements  studies. 

o  Closed  Figure:  this  is  a  primitive  that  is  a  composite  of 
other  primitives  and  which  is  a  filled  primitive  like 
POLYGON.  Lines,  arcs,  rectangles,  polygons,  etc.,  can  be 
strung  together  to  form  a  complex  shape  which  is  treated  as 
a  single  primitive. 

Altogether  there  are  31  new  functions  in  CGM  Addendum  1.  Several 
are  required  to  implement  each  of  the  above  two  capabilities. 
Several  others  will  be  required  in  order  to  make  the  needed 
features  work  properly. 

Recommendation:  the  features  of  CGM  Addendum  1  should  be 

adopted  in  MIL-D-28003A  as  indicated  in  Table  1.  Estimated  date 
of  stability:  January  1990. 


9 


TABLE  1.  Recoimiiendations  -  CGM  Addendum  1  Function  List 


Addendum  1  Element 

Recommendation 

Notes 

Begin  Segment 

include 

1 

End  Segment 

include 

Pick  Identifier 

exclude 

2 

Copy  Segment 

include 

Inheritance  Filter 

include 

3 

Clip  Inheritance 

exclude 

Segment  Transformation 

include 

Segment  Highlighting 

exclude 

Segment  Display  Priority 

include 

Segment  Pick  Priority 

exclude 

Segment  Priority  Extent 

include 

Maximum  VDC  Extent 

include 

Device  Viewport 

include 

4 

Device  Viewport 

Specification  Mode 

include ; 1 imit  to  0,1 

5 

Device  Viewport  Mapping 

include 

Line  Representation 

exclude 

6 

Marker  Representation 

exclude 

6 

Text  Representation 

exclude 

6 

Fill  Representation 

exclude 

6 

Edge  Representation 

exclude 

6 

Line  Clipping  Mode 

include;  limit  to  SHAPE 

7 

Marker  Clipping  Mode 

include;  limit  to  SHAPE 

7 

Edge  Clipping  Mode 

include;  limit  to  SHAPE 

7 

Begin  Figure 

include 

End  Figure 

include 

New  Region 

include 

Connecting  Edge 

include 

Save  Primitive  Attributes 

exclude 

Restore  Primitive  Attributes 

exclude 

Circular  Arc  Center  Reversed 

include 

Notes: 

1.  Both  Global  Segments  and  Local  Segments  should  be  allowed. 
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2.  As  CGM  Addendum  1  states,  the  meaning  of  PICK  IDENTIFIER  is 
not  standardized  and  is  by  agreement  between  generator  and 
interpreter.  Its  use  is  application  dependent  and  it  should 
therefore  not  be  included  in  the  profile. 

3.  For  the  way  that  internal  symbols  are  most  likely  to  be  used 
in  engineering  applications,  both  values  of  the  INHERITANCE 
FILTER  are  needed.  For  value  STATE_LIST,  the  defined  symbol 
has  no  attached  attribute  but  inherits  it  from  the  context 
into  which  it  is  instanced.  For  example  one  might  define  a 
colorless  symbol  and  then  set  the  color  just  before 
instancing  the  symbol  into  a  picture.  For  SEGMENT,  the 
symbol  has  the  attributes  in  effect  at  the  time  of  its 
definition.  For  example  a  certain  dash  pattern  might  be 
required  for  some  lines  within  the  symbol.  Inheritance  is 
specified  on  a  per-attribute  basis,  and  it  is  easy  to 
postulate  examples  that  require  mixing  modes  within  one 
symbol  (e.g.,  combine  the  two  examples  above). 

4.  This  should  supersede  the  Escape  -302  of  MIL-D-280C".  It  is 
precisely  the  same  function.  Since  this  Escape  has  never 
been  seen  in  practice,  NIST/NCSL  thinks  it  is  safe  to  simply 
remove  it  from  the  profile  rather  than  leaving  it  in  and 
deprecating  its  usage. 

5.  Value  0  is  ••fractional”,  like  the  current  Escape  -302. 
Value  1  is  "millimeters”.  Value  2  is  native  device  units, 
which  is  device  dependent  and  should  be  disallowed  in  the 
profile. 

6.  While  these  functions  provide  something  of  a  useful  macro 
capability  for  some  attributes,  no  applications  in  the  US 
are  using  bundled  attributes  and  no  requirement  for  these 
capabilities  has  yet  been  identified  by  CALS. 

7.  There  appears  to  be  no  need  for  LOCUS  clipping  (see  Addendum 
1  text)  but  there  is  definite  need  for  SHAPE  clipping. 
Unfortunately  the  Addendum  1  default  is  LOCUS  so  these 
elements  must  be  included  to  override  the  default. 

In  addition  to  the  new  functions  of  CGM  Addendum  1  there  are  some 

new  rules  for  using  existing  functions: 

1.  COLOR  TABLE  and  PATTERN  TABLE  can  occur  in  the  Picture 
Descriptor  as  well  as  the  Picture  Body,  and  use  within  the 
Picture  Body  is  discouraged.  This  solves  (in  Addendum  1) 
the  problem  that  MIL-D-28003  dealt  with  by  restrictions  on 
placement  and  usage  of  the  two  elements. 


11 


2. 


Several  of  the  Picture  Descriptor  elements  -  COLOR  SELECTION 
MODE,  LINE  WIDTH  SPECIFICATION  MODE,  MARKER  SIZE 
SPECIFICATION  MODE,  EDGE  WIDTH  SPECIFICATION  MODE  -  may  now 
appear  in  the  Picture  Body.  This  is  required  in  order  to 
make  Global  Segments  work  properly.  With  the  exception  of 
the  color  mode,  which  can  be  tedious  to  switch,  the  elements 
are  not  particularly  difficult  for  implementations  to  deal 
with  in  a  Picture  Body. 


3.6  Registration:  Status  &  Recommendations 

There  are  three  batches  of  registration  proposals  currently  in 
progress  and  a  fourth  being  formulated.  The  content  of  each  is 
looked  at  below  and  a  decision  proposed  whether  it  should  be 
included  in  MIL-D-28003A  or  deferred. 


Batch  1. 


These  comprise  the  engineering  line  types  and  hatch  styles  which 
are  already  included  in  MIL-D-28003.  All  of  these  have  now  been 
approved  by  the  ISO  authority  except  for  some  of  the  hatch 
styles.  Those  hatch  styles  have  been  rejected  because  they  did 
not  meet  the  ISO  definition  of  hatch. 

The  ISO  authority  should  be  assigning  positive  registration 
indices  within  a  few  months.  MIL-D-28003A  should  use  the 
positive  indices.  Because  no  instance  of  the  negative  indices  of 
original  MIL-D-28003  have  been  encountered,  NIST/NCSL  feels  that 
the  negative  values  can  be  safely  prohibited  rather  than  allowed 
but  deprecated. 

Recommendation:  The  negative  indices  in  MIL-D-28003  be 
replaced  with  the  positive  ISO  register  indices  where  applicable. 
Expected  timetable:  May  1990. 

"No.”  in  the  following  table  heading  refers  to  the  registration 
proposal  number. 
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TABLE  2.  Batch  1  Registration  Proposals 


No. 

Description 

Recommendat ion 

Notes 

2 

Line type.  Single  Arrow 

change  index 

3 

Linetype,  Single  Dot 

change  index 

4 

Linetype,  Double  Arrow 

change  index 

5 

Linetype,  Stitch  Line 

change  index 

6 

Linetype,  Chain  Line 

change  index 

7 

Linetype,  Center  Line 

change  index 

8 

Linetype ,  Hidden  Line 

change  index 

9 

Linetype ,  Phantom  Line 

change  index 

10 

Linetype,  Break  Line  1 

change  index 

11 

Linetype,  Break  Line  2 

change  index 

12 

Hatch  Style,  cast  iron  ... 

change  index 

13 

Hatch  Style,  steel 

change  index 

14 

Hatch  Style,  bronze,  brass,  ... 

change  index 

15 

Hatch  Style,  white  metal. 

zinc,  . . . 

change  index 

16 

Hatch  Style,  magnesium. 

aluminum,  . . . 

change  index 

17 

Hatch  Style,  rubber,  plastic, . . 

change  index 

18 

Hatch  Style,  cork,  felt,  ... 

change  index 

19 

Hatch  Style,  sound  insulation 

undeteirmined 

1 

20 

Hatch  Style,  thermal  insulation 

change  index 

21 

Hatch  Style,  titanium  ... 

change  index 

22 

Hatch  Style,  concrete 

undetermined 

1 

23 

Hatch  style,  marble,  slate,  ... 

change  index 

25 

Hatch  Style,  rock 

change  index 

26 

Hatch  Style,  sand 

change  index 

27 

Hatch  Style,  water  and  other 

liquids 

undetermined 

2 

28 

Hatch  Style,  with  grain  wood 

undetermined 

2 

29 

Hatch  Style,  across  grain  wood 

undetermined 

2 

Notes: 

1.  Was  rejected  by  ISO;  continue  to  use  the  negative  index  of 
MIL-D-28003. 

2.  Was  rejected  within  X3H3  and  never  forwarded  to  ISO; 
continue  to  use  the  negative  index  of  MIL-D-28003. 
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Batch  2. 

This  batch  of  proposals  covers 

1.  finer  drawing  control  (line  cap,  join,  etc.)  such  as  found 
in  various  proprietary  systems  and  Page  Description 
Languages  (POLs) ; 

2.  user-defined  linetype; 

3.  advanced  geometry  (splines,  conics,  etc.). 

The  proposals  have  been  through  two  X3H3  ballot  and  review 
rounds.  The  resulting  proposals  are  now  being  sent  to  ISO.  The 
ISO  ballot  is  expected  to  end  sometime  in  February  1990.  It  is 
expected  that  these  can  be  included  in  this  revision  of 
MIL-D-28003.  All  of  these  are  high-priority  CALS  items,  and  all 
are  in  draft  Addendum  3,  in  substantially  the  same  form  (except 
for  user  line  type) . 

Recommendation:  The  registration  proposals  in  "batch  2" 

should  be  included  in  MIL-D-28003A  as  indicated  in  Table  3 . 
Estimated  date  of  stability:  November  1989. 

"No."  in  the  following  table  heading  refers  to  the  registration 
proposal  number. 


TABLE  3.  Batch  2  Registration  Proposals 


No. 

Description 

Recommenda t i on 

Notes 

Linetype  for  Setdash 

include 

1 

Set  Dash 

include 

1 

Set  Line  Cap 

include 

38 

Set  Line  Mitre  Limit 

include 

39 

Set  Line  Join 

include 

40 

Cubic  Bezier 

include 

41 

Conic  Arc 

include 

42 

Set  Conic  Arc  Transformation 

Matrix 

include 

43 

Parametric  Spline  Curve 

include 

44 

Rational  B-Spline  Curve 

include 

Notes: 

1.  The  two  functions  comprising  the  user-defined  line  type  are 
formulated  quite  differently  from  the  draft  Addendum  3  work. 
NIST/NCSL  thinks  that  the  problems  arising  from  an 
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architectural  distinction  in  Addendum  3,  which  will  be 
stable  within  2  years,  justify  using  the  Addendum  3 
formulation,  with  a  negative  ESCAPE  id,  rather  than  using 
the  registration  proposal  in  this  case. 


Batch  3. 

This  batch  contains  proposals  for  improvement  of  CGM  text 
capabilities.  These  are  high  priority  changes.  Getting  high 
quality  text  in  metafile  pictures  is  currently  one  of  the  most 
difficult  things  to  do  and  one  of  the  most  important  for 
publication  quality  graphics. 

Unfortunately  this  batch  is  also  the  furthest  from  completion  in 
the  X3H3  review  process.  There  has  been  one  ballot  and  review 
round.  There  were  heavy  comments,  and  these  will  likely  result 
in  significant  changes  to  the  proposals.  The  comments  have  been 
returned  to  the  proposer.  If  the  proposer  is  able  to  modify  the 
proposals  by  the  time  of  the  Nashua  X3H3  meeting  in  September, 
then  the  second  X3H3  review  round  could  take  place  before  the 
late  January  1990  X3H3  meeting,  and  it  is  possible  that  there 
would  be  a  set  of  final  proposals  to  go  to  ISO  around  February. 

According  to  the  2-review  criterion  noted  above,  it  would  then  be 
February  1990  before  any  proposals  were  mature  enough  to  put  into 
the  revisions  of  MIL-D-28003. 

Recommendation:  improvements  to  text  and  font  capability  are 
sufficiently  important  that  production  of  draft  text  for 
MIL-D-28003A  should  be  delayed  until  appropriate  registration 
items  are  advanced  enough  and  Fy90  work  supplies  other  needed 
definitions.  Estimated  timetable:  February  1990. 

There  was  strong  liaison  between  the  Registration  Item  proposer, 
the  NIST/NCSL  representative,  and  the  X3H3  CGM  experts  group 
before  and  at  the  September  X3H3  meeting  in  Nashua,  NH. 
NIST/NCSL  feels  that  enough  consensus  was  achieved  that  the  text 
capabilities  of  MIL-D-28003  can  be  improved  as  per  the  above 
recommendation.  (Note:  At  the  Nashua  meeting  there  was 
extensive  work  on  the  US  position  on  the  ISO  Working  Draft  of 
Addendum  3.  The  text  needs  of  CALS  as  reflected  in  the 
registration  proposals  should  be  nearly  identical  to  what  the  US 
wants  in  Addendum  3 . ) 

NIST/NCSL  thinks  it  likely  that  a  phased  approach  to  improving 
the  MIL-D-28003  text  capabilities  is  most  likely  to  succeed. 
Under  a  phased  approach  it  should  be  possible  to  identify  a 
relatively  small  number  of  not  too  difficult  extensions  that 
would  greatly  improve  the  capabilities  for  many  applications. 
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These  would  go  into  MIL-D-28003A.  Then  a  thorough  and  complete 
set  of  capabilities  would  go  into  the  next  revision, 
MIL-D“28003B.  The  time  frame  for  MIL-D-28003B  is  likely  to  be 
roughly  when  work  on  Addendum  3  is  substantially  complete. 

NIST/NCSL  understands  that  it  is  likely  that  the  proposals  in  the 
third  batch  will  be  substantially  revised  by  the  proposer. 
Therefore  NIST/NCSL  is  recommending  "include  when  stable"  with 
the  understanding  that  at  least  some  of  the  high  priority  text 
items  should  go  into  this  revision  of  the  profile. 

"No."  in  the  following  table  heading  refers  to  the  registration 
proposal  number. 

TABLE  4.  Batch  3  Registration  Proposals 


I 

I 

I 

I 

I 

I 


No. 

Description 

Recommendation 

Notes 

45 

Edge  Mitre  Limit 

include  when  stable 

46 

Edge  Cap 

include  when  stable 

47 

Edge  Join 

include  when  stable 

48 

Set  Italic  Text 

include  when  stable 

49 

Set  Outline  Text 

include  when  stable 

50 

Set  Shadow  Text 

include  when  stable 

51 

Set  Underline  Text 

include  when  stable 

52 

Set  Bold  Text 

include  when  stable 

53 

Set  Fully  Justified  Text 

include  when  stable 

54 

Set  Condensed  Text 

include  when  stable 

55 

Set  Extended  Text 

include  when  stable 

56 

Pel  Array 

include  when  stable 

1 

57 

Set  Indexed  Color  Response 

exclude 

2 

58 

Set  Direct  Color  Response 

exclude 

2 

Notes; 

1.  This  is  substantially  the  same  as  the  current  CGM  CELL  ARRAY 
except  that  compression  techniques  (CCITT  Group  3  and  Group 
4,  and  LZW)  are  added.  CGM  binary  encoded  CELL  ARRAY 
already  has  some  compression  capabilities.  These  are  being 
used  effectively  in  real  world  applications  -  NIST/NCSL  has 
seen  raster  images  of  512x512,  both  index  and  direct  color, 
encoded  in  30K-50K  bytes.  Given  this  fact,  the  Pel  Array 
may  not  be  as  high  priority  as  some  other  items.  This  will 
need  to  be  coordinated  closely  with  the  X3H3  CGM  experts, 
who  are  working  on  Addendum  3.  This  latter  work  is 
including  tiling  capabilities  such  as  those  found  in  the  ISO 
8613/8  tiling  addendum  and  in  MIL-R-28002.  The  topic  of 
color  compression  needs  some  work  as  well. 
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2.  The  need  for  advanced  color  capabilities  in  MIL-D-28003  is 
uncertain.  It  appears  that  the  majority  of  use  is  going  to 
be  for  bi-level  black  &  white  or  grayscale  work. 
Accordingly  NIST/NCSL  thinks  these  proposals  can  be  assigned 
lower  priority. 

In  addition  to  the  attribute  selection  capabilities  of  these 
proposals  the  revised  text  functionality  of  MIL-D-28003A  should: 

1.  allow  in  metafiles  and  mandate  for  interpreters  the  fonts 
Helvetica,  Times  Roman,  Courier  or  their  metric  equivalents. 
These  are  copyrighted  or  trademarked  names  but  virtually 
every  publishing  system  has  the  metric  equivalent  available. 

2.  define  how  to  use  the  FONT  LIST  to  name  a  font  resource  at 
varying  levels  of  specificity,  from  the  capability  to 
unambiguously  name  a  particular  resource  to  the  capability 
to  call  out  a  class  of  fonts  based  on  some  attributes  (e.g., 
state  that  any  "serif  bold"  font  will  do) . 

3.  define  how  to  use  the  attributes  of  the  above  registration 
proposals,  within  the  body  of  the  metafile,  in  combination 
with  the  FONT  LIST  mechanism. 

4.  define  how  to  use  symbol  and  character  sets  that  do  not  fit 
well  within  the  ISO  2022  model  of  character  sets  and 
character  set  switching. 

5.  define  for  metafiles  and  interpreters  how  to  specify 
character  codes  for  the  dozen  (approximately)  character  sets 
needed  to  support  IGES  drawings  and  SGML  fonts. 

These  topics  were  discussed  at  the  Nashua  meetings.  Except  for 
the  last  two,  detailed  recommendations  can  now  be  prepared  based 
on  existing  material  in  registration,  draft  Addendum  3,  and  NIST 
requirements  studies. 


3 . 7  Other  Recommendations 
3.7.1  Baseline  Docvment 

The  original  CGM  standard  was  published  in  both  a  US  version  and 
an  ISO  version.  The  US  version  is  an  ANSI  standard  ANS 
X3. 122-1986.  The  ISO  version  is  designated  ISO  8632/1-4:1987. 
They  are  identical  except  for  document  style  and  layout.  The 
ANSI  document  was  adopted  by  FIPS  PUB  128,  which  in  turn  is  the 
baseline  document  that  is  referenced  in  MIL-D-28003.  X3H3  is 
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currently  working  on  getting  domestic  CGM  work  redesignated  as  an 
"international  project".  By  these  procedures  the  main  technical 
work  takes  place  in  ISO  committees  v'ith  US  participation.  US 
public  review  of  the  resulting  milestone  ISO  documents  is 
automatic,  as  is  the  adoption  of  the  final  result  as  an  ANSI 
standard. 

In  reality  this  is  exactly  how  work  has  been  taking  place  for  the 
last  several  years.  Giving  the  project  this  new  designation  will 
mean  that  X3H3  does  not  have  to  have  a  US  document  editor  to 
revise  the  ISO  document  stylistically,  and  does  not  have  to 
conduct  tedious  parallel  voting  and  review  procedures.  In  the 
end  there  will  only  be  one  document,  an  ISO  document. 

X3H3  intends  X3. 122-1986  to  be  replaced  by  ISO  8632/1-4:1987  and 
CGM  Addendum  1  to  be  handled  by  the  new  procedures.  NIST/NCSL 
will  be  revising  the  FIPS  designation  of  CGM  to  reflect  this,  but 
will  not  do  so  until  X3H3  has  obtained  formal  approval.  In  the 
interim: 

Recommendation:  MIL-D-28003  should  be  revised  to  point  to  the 
appropriate  ISO  documents  for  CGM  and  addenda  until  they  get  FIPS 
designations. 


3.7.2  METAFILE  VERSION 

The  MIL-D-28003A  will  include  some  of  the  functionality  of  CGM 
Addendum  1.  Metafiles  conforming  to  CGM  Addendum  1,  and  using 
new  capabilities,  will  have  a  METAFILE  VERSION  value  of  2.  The 
original  CGM  is  a  proper  subset  of  CGM  Addendum  1  (proper 
terminology  is  uncertain  here  -  CGM  Addendum  1,  or 
CGM-plus-Addendum-1 ,  or...).  A  legal  ISO  8632:1987  metafile  will 
be  a  legal  ISO  8632/AD.  1 : 1989  metafile.  Such  a  file  may  have 
METAFILE  VERSION  value  of  1. 

Recommendation:  The  Basic  Values  of  METAFILE  VERSION  shall  be 

1  or  2 . 


3.7.3  METAFILE  DESCRIPTION  substring 

Metafiles  corresponding  to  MIL-D-28003  must  contain  a  substring 
"MIL-D-28003/BASIC-1"  (case  insensitive)  in  the  string  of 
METAFILE  DESCRIPTION,  to  identify  the  metafile  as  a  CALS 
metafile.  This  requirement  will  need  to  be  revised. 

Recommendation:  The  METAFILE  DESCRIPTION  element  shall 

contain  the  substring  "MIL-D-28003A/BASIC-1" . 
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3.7.4  Escape  -302 

The  current  Escape  -302  is  a  device  viewport,  identical  to  a 
function  which  will  be  adopted  from  CGM  Addendum  1. 

Recommendation:  Remove  Escape  -302  from  MIL-D-28003. 


3.7.5  An  Additional  Hatch  Style 

Registration  proposal  #59  defined  an  additional  hatch  style  which 
consists  of  a  pattern  of  alternating  dots.  The  proposal  has  been 
accepted  by  X3H3. 

Recommendation:  Include  the  hatch  style  of  registration 

proposal  #59  in  the  Basic  Set  of  MIL-D-28003A. 


3.7.6  Text  Precision  &  Append  Text 

The  CGM  standard  allows  TEXT  PRECISION  to  be  changed  between 
partial  text  strings  which  are  appended  Ihe  intended  results 
are  nearly  impossible  to  figure  out,  and  will  be  highly 
implementation  dependent.  MIL-r -28003  should  prohibit  this. 

Recommendation:  The  TEXT  PRECISION  element  shall  not  occur 
between  non-final  TEXT,  RESTRICTED  TEXT,  or  APPEND  TEXT  and 
following  APPEND  TEXT  in  conforming  basic  metafiles. 


3.7.7  Private  Additions  to  Parameter  Lists 

Files  have  been  encountered  in  which  private  parameters  have  been 
added  to  parameter  lists  of  elements.  This  occurs  on  elements 
with  fixed-length  parameter  lists,  and  the  Parameter  List  Length 
of  the  binary  element  header  is  adjusted  appropriately  to  include 
the  private  data.  The  CGM  standard  does  not  specifically 
prohibit  the  practice,  but  there  are  ample  indications  that  it 
should  not  be  legal.  The  Metafile  Maintenance  Rapporteur  Group 
is  likely  to  rule  that  this  is  illegal.  In  the  meantime: 

Recommendation:  The  Parameter  List  Length  of  elements  in 
conforming  basic  metafiles  shall  be  as  indicated  in  the  tables  of 
the  CGM  Binary  Encoding  (Part  3)  ;  in  particular  no  private 
parameters  shall  be  added  to  elements. 
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3.7.8  Use  of  Font  Indices 

One  of  the  biggest  impediments  to  predictable  interchange  is  the 
failure  to  define  required  font  indices. 

Recommendation:  All  font  indices  which  are  explicitly  used  in 

the  metafile  shall  be  defined  in  the  FONT  LIST. 


3.7.9  Color  vs.  Black-and-white 

The  necessity  of  supporting  a  rich  color  model  has  been 
questioned.  Much  technical  publishing  and  engineering  drawing 
work  needs  no  more  than  bi-level  black  &  white,  or  multi-level 
grayscale.  It  is  uneconomic  to  force  all  CALS-compliant 
suppliers  to  have  full  color  capability. 

Recommendation:  MIL-D-28003A  should  have  mechanisms  and 
structure  so  that  full  color,  black  &  white,  and  grayscale 
implementations  are  all  recognized  as  conforming  implementations. 

Note;  this  is  one  aspect  of  a  more  general  "levelling"  or 
"structuring"  issue  which  is  being  raised  now  about  CALS 
conformance. 


3.7.10  Temporal  Priority 

Many  metafiles,  particularly  those  coming  from  graphics  arts 
packages,  assume  that  the  recipient  device  is  a  "temporal 
priority"  device.  This  means  that  objects  occurring  later  in  the 
file  overlay  and  obscure  objects  occurring  earlier  in  the  file. 
This  assumption  works  fine  on  raster  display  monitors,  raster 
driven  slide  cameras,  and  various  high  quality  plotters.  But  on 
certain  COM  devices  which  are  not  driven  from  a  frame  buffer  and 
on  pen  plotters  such  as  those  sometimes  used  in  drafting  and 
design  this  assumption  causes  problems.  A  descriptor  element  has 
been  proposed  which  would  declare  whether  the  file  contents 
assume  temporal  priority  or  not.  There  has  not  yet  been  a 
concrete  proposal  for  either  registration  or  addendum  3. 

Recommendation:  MIL-D-28003B  should  have  an  ESCAPE,  which 
occurs  in  the  Metafile  Descriptor,  which  declares  whether 
temporal  priority  is  assumed  for  successful  interpretation  and/or 
rendering  of  the  file. 
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3.7.11  I/O  and  Record  Formats 


MIL-D-28003  inherited  from  TOP  certain  specifications  concerning 
the  size  of  records  and  tape  blocks  for  metafiles.  This 
specification  has  been  widely  criticized.  It  does  not  appear  to 
belong  in  MIL-D-28003  itself,  but  is  more  properly  dealt  with  at 
the  next  higher  level  -  MIL-STD-1840A  -  or  left  to  supporting 
data  transport  services  in  the  computing  support  environment. 

Recommendation:  The  record  formatting  specifications  of 
MIL-D-28003  should  be  removed,  and  the  specifications  of 
MIL-STD-1840A  ensured  to  be  adequate  for  successful  interchange 
over  the  specified  media. 


3.7.12  Levels  and  Stznicturing 

It  is  now  becoming  clear  that  it  will  not  be  economic  for  the 
CALS  program  to  force  conformance  of  all  suppliers  to  all 
possible  specifications  in  the  second  version  of  the  profile, 
MIL-D-28003A.  There  are  two  particular  areas  where  this  is  true: 
color  vs  monochrome;  and  character  set,  glyph  collection,  font 
support.  By  example,  a  system  which  is  designed  to  handle  the 
equivalent  of  IGES  engineering  drawings  should  be  required  to 
carry  the  full  color  capability  and  dozen  SGML  glyph  collections 
that  a  high  quality  technical  illustration  system  might  have  to 
support.  To  force  conformance  of  all  suppliers  to  all  possible 
specifications  will  unnecessarily  force  up  the  government's 
acquisition  costs  for  the  components  to  implement  CALS  systems. 
However,  any  leveling  or  structuring  must  be  designed  clearly  and 
minimally  so  that  it  does  not  require  technical  expertise  for 
procurement  officers  to  specify  in  contracts  what  is  needed  in  a 
system. 

Recommendation:  MIL-D-28003A  should  have  some  minimal 
packaging,  levelling,  or  structuring  to  account  for  the  different 
application  requirements  that  are  all  being  addressed  by  CGM. 

This  aspect  of  the  revision  will  be  addressed  in  FY90. 


4.  The  Presentation  Problem 

A  potential  interchange  problem  was  raised  in  a  series  of 
communications  early  in  FY89 .  These  communications  were  between 
members  of  the  CALS  Industry  Standards  Working  Group.  The 
problem  can  be  summarized  as  a  "presentation  problem."  Briefly 
the  issue  is:  how  are  the  separate  contents,  such  as  CGM 
illustrations,  IGES  drawings,  etc.,  assembled  and  positioned 
within  viewports  in  the  complete  document? 
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During  this  fiscal  year,  the  NIST/NCSL  representative  began  to 
contact  people  in  the  working  group  who  are  interested  in  the 
problem  and  are  addressing  it.  Results  are  incomplete  at  this 
time.  Progress  on  this  question  will  be  entirely  dependent  upon 
the  pace  of  an  ad  hoc  group  which  has  been  set  up  to  investigate 
it,  and  which  has  not  yet  met. 

Recommendation:  The  work  of  this  ad  hoc  group  should  be 
tracked  in  FY90  and  any  implications  for  the  profile  should  be 
accounted  for  in  MIL-D-28003A. 


5.  Future  Work 

The  recommendations  of  this  report  should  be  implemented  in  FY90 
by: 

1.  by  following  the  appropriate  work  in  the  standards  and 
registration  bodies; 

2.  producing  draft  text  for  MIL-D-28003A; 

In  addition,  the  CALS/TOP  reconciliation  and  consolidation  should 
continue  to  be  pursued  at  the  technical  level  once  agreement  is 
established  at  the  administrative  level. 
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6 .  Glossary 


AFNOR 

ANS 

ASC  X3H3 

BSI 

CGEM 


CGI 


CGH 


DAO 


DIN 


The  French  equivalent  of  ASC  X3H3 . 

American  National  Standard,  the  final 
stage  in  the  ANSI  pipeline,  nothing 
remains  but  possibly  the  printing. 

Accredited  Standards  Committee  X3H3,  the 
ANSI  accredited  committee  responsible 
for  computer  graphics  standards  in  the 
US. 


British  Standards  Institute,  the  British 
equivalent  of  ASC  X3H3 . 

Computer  Graphics  Extended  Metafile,  a 
set  of  addenda  and  extensions  to  CGM, 
being  processed  by  ISO,  currently 
nearing  DP  stage. 

Computer  Graphics  Interface,  another 
ANSI/ISO  standards  project,  currently  at 
the  2nd  DP  stage.  CGI  is  an  interface 
standard  which  exists  about  at  the  level 
of  the  CGM  in  the  graphics  reference 
model  (device  level)  .  CGI  is  an 
interactive  (input)  and  highly  extended 
and  enriched  interface  specification, 
whereas  CGM  has  output-only 
functionality  (for  picture  definition) 
and  is  a  picture  description  protocol  (a 
graphical  database) .  CGI  embeds  CGM 
output  functionality  as  a  subset. 

Computer  Graphics  Metafile,  ANSI 
standard  X3. 122-1986  and  ISO  standard 
ISO  8632/1-4  1987. 

Draft  Addendum,  the  same  as  DIS,  but  for 
an  addendum  as  opposed  to  a  standalone 
project. 

The  German  equivalent  of  ASC  X3H3 . 
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DIS 


Draft  International  Standard,  the 
project  stage  in  the  ISO  pipeline  after 
DP.  The  technical  content  of  the 
project  is  supposedly  highly  stable  and 
it  is  expected  that  IS  text  can  be 
produced  subsequent  to  processing  the 
DIS  ballot  results. 

DP  Draft  Proposal,  the  second  stage  in  the 

ISO  processing  pipeline.  After  national 
bodies  have  conmented  on  the  WD,  it  is 
altered  and  refined  and  then  registered 
as  a  DP.  Another  round  of  ballot  and 
comment  takes  place  on  the  DP. 

GDP  Generalized  Drawing  Primitive,  a  CGM 

element  which  is  a  catch-all  for 
geometric  primitives  which  are  not 
standardized  in  the  CGM  standard  itself. 
These  are  private  or  user  defined 
primitives.  GDPs  also  may  be  submitted 
for  graphical  registration. 

GKS  Graphical  Kernel  System,  an  application 

programmer  interface  to  computer 
graphics,  now  an  ANSI  and  ISO  standard. 

GKSM  A  metafile  for  use  with  GKS.  One  was 

proposed  in  non-standard  Annex  E  of  GKS. 
Work  on  it  was  deferred  in  favor  of  CGM, 
and  now  of  extended  CGM  (CGEM) . 

Graphical  Registration  A  process  by  which  private  geometric 

primitives  (GDPs  such  as  Pel  Array) , 
private  control  functions  (ESCAPES  such 
as  Set  Dash),  and  private  types  (e.g.,  a 
private  line  type)  is  given  a  fixed 
identifier  and  entered  in  a  central  ISO 
register.  The  item  thereby  becomes 
accessible  in  a  uniform  manner  to  all 
users,  and  can  be  thought  of  as  having 
"semi-standard”  status. 

IS  International  Standard,  the  final  stage 

in  the  ISO  pipeline,  nothing  remains  but 
possibly  the  printing. 

ISO  TC97/SC21/WG2  The  predecessor  to  SC24  (prior  to 

December  1987) . 
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ISO/IEC 


MR6 


PDAD 


PHI6S 


WD 


WG3 


X3H3 . 3 


JTC1/SC24  International  Standards  Organization, 

Joint  Technical  Committee  1,  Standing 
Committee  24,  the  international 
counterpart  to  X3H3 . 

Metafile  Rapporteur  Group,  the  sub-group 
of  WG3  responsible  for  CGM  maintenance 
and  CGM  extensions. 

Proposed  Draft  Addendum,  the  same  as  DP, 
but  for  an  addendum  as  opposed  to  a 
stand  alone  project. 

Programmers  Hierarchical  Interactive 
Graphics  System,  an  application  programmer 
interface  to  computer  graphics,  with  3D, 
structure  hierarchy,  etc.,  meant  to  be 
highly  dynamic.  It  is  nearly  completed 
as  an  ANSI  and  ISO  standard. 

Working  Draft,  the  first  complete  draft 
of  a  proposed  ISO  standard,  the  starting 
document  for  subsequent  work  and  review. 

The  working  group  of  SC24  responsible  for 
standards  work  in  metafiles  and 
device-level  interfaces,  i.e.,  CGM  and 
CGI. 

The  subcommittee  of  X3H3  that  is 
responsible  for  CGM  and  CGI. 
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Attachment  i: 
Liaison  Documents  to  TOP 
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4  August  1989 


Mr.  Kem  Hardman 
Boeing  Computer  Services 
P.O.  Box  24346 
Seattle,  WA  98124 


Dear  Kem, 

I'm  writing  in  my  capacity  as  a  CALS  consultant  on  maintenance  and 
extension  of  MIL-D-28003,  the  CALS  application  profile  of  CGM.  I'd 
like  to  follow  up  on  our  conversation  at  NCSA,  when  we  discussed  how 
to  maintain  consistency  between  the  MAP/TOP  and  CALS  application 
profiles.  To  sximmarize  that  conversation:  we  concluded  that 
maintenance  of  separate  and  complete  documents  for  the  TOP  CGM  AP 
and  the  CALS  CGM  AP  (MIL*~0-28003)  no  longer  appears  desirable. 

This  is  not  to  say  .  that  the  APs  should  be  identical .  That  should 
only  be  the  case  if  our  respective  user  communities  are  identical 
and  have  identical  requirements.  We  have  not  concluded  that  to  be 
the  case.  However,  our  respective  user  commtinities  are  very 
similar,  and  we  did  conclude  that  where  their  functional 
requirements  overlapped,  then  the  AP  specifications  pertaining  to 
those  requirements  should  be  identical.  In  other  words,  one  AP 
might  contain  capabilities  or  specifications  that  the  other  does  not 
contain  and  does  not  intend  to  contain,  but  where  the  APs  overlap 
they  should  be  identical. 

We  have  really  had  this  goal  from  the  beginning,  as  the  CALS 
community  reviewed  and  participated  in  the  specification  of  the  TOP 
profile,  and  vice-versa.  We  have  not  quite  realized  our  goal.  This 
is  probably  inevitable  given  our  distinct  processing  methods,  review 
procedures  and  timetables.  In  these  circumstances  It  is  inherently 
difficult  to  maintain  two  complete  documents  and  keep  them  identical 
in  overlapping  areas. 

There  are  a  two  practical  possibilities  for  maintaining  a  single 
document.  The  first:  we  could  try  to  encapsulate  the  APs  of  the  TOP 
and  CALS  communities  as  distinct  specifications  in  the  single 
document.  The  second:  we  could  wrxte  the  document  to  specify  the 
"larger"  AP  and  have  the  second  AP  be  a  "delta  document"  against  the 
complete  document. 

From  a  procedural  point  of  view,  the  second  approach  appears  most 
likely  to  achieve  our  goals.  The  principle  reason  is  that  it  allows 
the  two  communities  to  continue  to  have  their  autonomous  review 


cycles  and  procedures ,  and  a't  'the  same  time  it  ensures  that  the 
profiles  stay  highly  compatible  because  there  is  ever  only  one 
complete  document. 

At  this  point  the  CALS  AP  appears  to  be  the  larger  AP,  i.e.,  it  has 
more  specifications  and  restrictions,  and  has  added  more 
functionality  as  well.  From  our  conversations,  it  appears  that 
likely  that  this  will  continue  to  be  true.  He  anticipate  that  the 
CALS  AP  will  be  ammended  in  the  next  year  or  so  to  add 
specifications  from  CGM  Addendum  1,  from  Graphical  Registration, 
etc. 

If  we  agree  to  this  approach,  MIL>>0-28003  would  become  the  base 
document  for  bo'th  the  CALS  AP  and  the  TOP  AP.  The  current  TOP  AP 
would  be  replaced  by  a  document  that  points  to  MIL-0-28Q03,  and 
specifies  changes,  deletions,  and  limitations.  The  TOP  community 
would  participate  in  'the  revision  of  the  base  document  by  forwarding 
new  requirements  to  CALS,  and  proposed  ammendments  to  the  CALS  AP 
would  be  circulated  to  the  TOP  community  for  review  and  comment. 

When  MIL-0-28003  is  ammended  then  the  TOP  community  would  decide  how 
and  when  to  revise  its  profile  to  be  based  on  the  new  common 
document.  This  should  work  smoo'thly,  particularly  as  we  both  have  a 
strong  goal  of  keeping  the  revised  profiles  backwardly  compatible 
with  previous  versions. 

The  question  that  we  must  now  address  is:  how  do  we  implement  this? 

I  think  there  are  two  steps:  firstly,  we  reaffirm  that  we  intend  to 
proceed  in  this  way;  secondly,  the  TOP  AP  would  be  replaced  with  a 
new  document  which  paints  to  the  MIL-0-28003  document. 

I  think  having  an  exact  list  of  differences  between  the  current 
version  of  the  two  APs  would  help  in  both  steps:  it  will  let  you 
evaluate  the  implications  of  making  the  change;  and  it  will  give  you 
the  basic  "raw  material"  for  writing  the  delta  document. 

Accordingly,  I  have  reviewed  and  compared  both  documents  and 
produced  a  list  of  differences  of  sxibstance.  The  list  is  enclosed. 
For  eac.h  list  item,  I  have  included  a  brief  assessment  of 
implications  for  TOP  —  whether  the  item  seems  like  a  good  idea  in 
general  or  is  really  CALS-specific. 

Could  you  please,  at  your  earliest  convenience,  get  in  touch  and 
give  me  your  current  though'ts  on  the  matter,  and  your  ideas  on  how 
best  to  proceed?  I  think  this  is  something  that  we  should  be  able 
to  take  care  of  fairly  easily,  with  beneficial  results  for  our  two 
closely  related  user  communities. 


Sincerely  yours. 


Lofton  R.  Henderson 
President,  Henderson  Software 
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Differences  between  the  TOP  and  CALS 
Application  Profiles 

1.  The  Metafile  Description  element  in  TOP  contains  the  svibstring 
T0F/BASIC~1,  whereas  in  CALS  it  contains  the  substring 
MIL-D-28003/BASIC-1.  Assessment;  both  TOP  and  CALS  should  keep 
their  unique  substrings  to  identify  the  profile. 

2.  The  Metafile  Description  element  in  CALS  is  required  to  have  a 
substring  identifying  toe  source  (company  and  product) .  In  TOP 
this  is  only  a  suggestion.  Assessment:  experience  has  shown  id 
information  to  be  very  valuable,  it  shotild  be  valxiable  for  TOP. 

3.  TOP  allows  interpreters  to  use  only  the  Hershey  fonts  for 
rendering  pictures.  CALS  allows  toe  use  of  any  font  which  is 
"metrically  identical"  to  a  requested  Hershey  font.  Assessment: 
toe  CALS  specification  is  foraulated  to  give  identical  results, 
metrically/  to  the  TOP,  and  it  does  give  implementors  more 
freedom  and  the  option  of  producing  better  quality.  Its 
adoption  should  be  seriously  considered  for  TOP. 

4 .  CALS  has  added  ?  ’^'omber  of  additional  line  types  and  hatch 
styles  for  engineering  applications.  Assessment:  CALS 
identified  a  requirement  for  these.  TOP  has  not  identified  such 
a  requirement,  and  so  might  well  eliminate  these  for  the  TOP  AP. 

5.  CALS  has  ^ecified  two  conformance  levels  for  interpreters 
(Publication  Level  and  Draft  Level) ,  whereas  TOP  specified  only 
one.  ^  Assessment:  The  two  levels  arose  in  CALS  as  a  result  of 
considering  the  implications  of  forcing  all  interpreters  to 
implement  the  profile  fully,  for  complete  uniformity ' and 
predictability.  This  would  essentially  mean:  no  fallbacks,  no 
monochrome  interpreters,  etc.  For  publication  this  is  in  fact 
required.  For  development  it  seemed  excessive,  and  would  make 
all  interpreters  more  expensive  and  resource  intensive.  CALS 
thinks  that  the  distinction  is  a  useful  one.  TOP  should 
consider  having  this  specification. 

6.  CALS  and  TOP  differ  somewhat  on  their  reference  to  Annex  D.  CALS 
goes  into  more  detail,  and  makes  distinctions  based  on  Draft 
Level  versus  Publication  Level.  TOP  doesn't  define  conformance 
level  precisely  (does  it  intend  something  more  like  Publication 
or  Draft?  It  appears  toe  former)  ,  and  which  fallbacks  of  Annex  D 
are  allowed  is  not  completely  clear.  Assessment:  The  intent 
appears  to  be  toe  same.  The  effective  specification  perhaps 
would  be  identical  if  the  APs  both  bad  the  same  conformance 
level  structure.  If  TOP  adopts  toe  two— level  structure,  toe 
references  could  be  identical.  If  not,  then  toe  TOP  AP  would 
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need  its  own  Atinex  0  relTerence,  which  prestunably  wou^d  be  a 
clarification  of  the  current  one. 

7.  There  is  a  note  in  CALS  suggesting  that  the  first  three  elements 
of  the  metafile  be,  in  order.  Metafile  Version,  Metafile  Element 
List,  and  Metafile  Description.  This  apparently  will  not  be  a 
feattire  of  CGM  Addendum  1  as  originally  emticipated ,  but  is 
still  thought  to  be  useful.  Assessment:  it  is  useful,  and  in 
its  current  form  of  a  non-binding  suggestion  should  not  cause 
any  problems  for  TOP. 

8.  In  CALS  the  behavior  of  the  Device  Viewport  escape  has  been 
clarified  and  brought  into  alignment  with  the  specifications  of 
ISO  CGI  and  the  ISO  CGM  Addendum  1.  It  is  not  clear  whether  this 
is  slightly  different  from  what  is  intended  in  TOP  or  simply  a 
more  precise  statement  of  the  same  requirement.  Assessment:  we 
assiuae  the  latter,  and  so  this  should  not  be  objectionable  to 
TOP. 

9.  The  loaximum  string  length  is  256  in  CALS  euid  254  in  TOP.  256  is 
somewhat  of  an  arbitral  choice,  being  based  around  some 
perceived  limitations  of  popular  computer  systems.  However  some 
systems  actually  cannot  go  longer  than  255.  The  longest  string 
express2dble  in  a  short-format  CGM  binary  text  string  is  254. 
Assessment:  there  does  not  seem  to  be  any  requirement  for  256 
over  254;  compatibility  between  TOP  and  CALS  should  pertain  in 
this  case. 

10.  The  Basic  values  of  Transparency  in  CALS  have  been  limited  to 
the  single  value  1  (on) .  The  effects  of  this  element  in  CGM 
itself  are  described  as  device  dependent  for  the  value  0  (off)  . 
Assessment:  no  requirments  for  value  0  (off)  have  been  stated, 
amd  a  lot  of  experience  has  failed  to  reveal  a  single  usage  of 
the  feature  in  practice.  Value  0  (off)  should  be  eliminated 
from  the  Basic  Set. 

11.  CALS  has  dropped  the  requirement  that  the  Metafile  Descriptor 
contain  the  Character  Set  List  element  listing  (0,4/1)  and 
(1,4/2).  The  vast  majority  of  applications  will  simply  use 
ASCII,  and  that  is  the  default,  so  announcing  the  requirement 
for  the  other  set  is  misleading.  Assessment:  it  is  thought  that 
this  TOP  specification  was  intended  to  effectively  require  that 
interpreters  support  both  sets.  This  is  already  achieved  by  the 
table  in  6.2. 6.2.  Since  it  presents  misleading  Information  to 
the  recipient  of  the  metafile,  TOP  should  drop  the 
specification . 

12 .  TOP  says  all  Color  Table  elements  must  appear  before  the  first 
graphical  primitives.  CALS  now  says  that  they  just  must  appear 
before  they  are  first  used  by  a  primitive  or  attribute. 
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Assessment:  the  effect  (preventing  color  dynamics)  is  the  same 
but  the  CALS  specification  is  easier  for  many  applications  and 
generators  to  implement;  TOP  should  have  this  specification. 

13.  The  previous  distinction  applies  to  Pattern  Table  elements  as 
well.  Assessment:  same. 

14.  There  is  no  requirement  for  color  index  definition  in  the 
metafile  ^  TOP.  CALS  now  requires  that  either  all  indexes  which 
are  used  in  a  metafile  be  defined,  or  none  be  defined.  The  case 
of  having  some  udexes  which  are  used  be  defined  and  some  not 
defined  is  prohibited.  Assessment:  experience  in  the  NCGA 
Integrate  demos  has  shown  that  partial  definition  of  color 
^dices  is  a  real  contributor  to  \inpredictable  and  sometimes 
inexplicable  results.  For  the  goal  of  interoper^ility  TOP 
should  have  this  specification. 

15 .  The  TOP  AP  defines  the  default  Color  Table  for  interpreters  to 
be  a  cyclic  repetition  of  the  colors  Red,  Green,  Blue,  Yellow, 
Magenta,  Cyan,  BlacJc,  White,  starting  at  index  2.  Indexes  0  and 
1  are  left  undefined.  In  the  default  case  CALS  now  specifies 
the  same  table  except  that  index  0  is  defined  to  be  white  and 
index  1  black.  CALS  allows  these  two  to  be  swappe:  in  Draft 
Level  inte^reters.  Assessment:  the  reasons  for  this 
specification  are  the  same  as  the  reasons  for  the  previous 
specification.  For  predictable  interchange  TOP  should  have  this 
specification. 

16.  CALS  has  added  an  Escape  element.  Implicit  Color  Table,  with 
Escape  Indicator  ->303.  This  element  allows  a  generator  to 
specify  how  interpreters  are  to  initialize  their  color  tables. 
One  option  is  "none",  which  means  the  interpreter  is  to  use  its 
native  color  capab^ities  as  best  it  can  and  initialize  its 
color  table  accordingly.  The  other  two  options  are  shorthands 
for  selecting  one  of  two  useful  initialization  schemes  —  the 
first  is  the  "izyclic"  scheme  (the  default  for  the  AP)  ,  and  the 
second  is  a  unifom  sampling  of  the  RGB  color  cube.  Assessment: 
this  was  thought  to  be  a  useful  feature  in  CALS;  TOP  should 
assess  whether  it  is  useful  for  its  constituency. 

17 .  CALS  has  defined  bow  metafile  color  requests  should  be  mapped  by 
Draft  Level  interpreters  when  the  output  device  is  only  capable 
of  two  levels  (foreground  and  backgrotind)  .  Assessment:  this 
removes  an  ambiguity .  Some  implementations  have  made  bad 
choices  here.  The  specification  improves  interoperability,  so 
should  be  useful  to  TOP. 

18.  CALS  specifies  what  shall  be  the  clipping  limits  in  all  cases. 
Assessment:  this  removes  a  CGM  ambiguity  and  improves 
interoperability,  so  should  be  useful  to  TOP. 
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19.  CALS  specifies  that  line  types  and  edge  types  shall  be  continued 
across  interior  vertices  of  a  polyline  or  polygon.  Assessment: 
this  removes  a  CCM  ambiguity  and  Improves  interoperedaility,  so 
should  be  useful  to  TOP. 

20.  In  CALS,  at  Publication  Level  all  text  must  be  rendered  at 
stroke  precision.  In  TOP,  all  metafiles  must  have  an  item  in 
the  Metafile  Defaults  Replacement  which  sets  text  precision  to 
stroke.  Assessment:  it  is  thought  that  the  CALS  specification 
achieves  what  was  intended  by  the  TOP  specification  (but  which 
is  not  achieved,  because  the  default  can  be  circumvented  by  cm 
explicit  precisian  setting  in  the  picture  body) . 

21.  The  TOP  document  has  some  description  of  generation  and 
interpretation  of  metafile  from  a  system  architecture 
standpoint.  Assessment:  there  is  no  problem  with  this  remaining 
in  TOP  if  CALS  is  used  as  the  base  document  for  TOP. 

22.  CALS  has  a  specification  that  the  character  set  selected  shall 
be  representable  in  the  font  selected.  Assessment:  this  is  not 
achieved  in  either  CALS  or  TOP  now,  because  Hershey  cannot 
represent  complete  ASCII;  it  is  nonetheless  a  desirable  goal  and 
should  be  stated. 

23.  CALS  has  a  section  correcting  known  errozrs  in  the  COM  standard. 
Assessment:  this  is  useful  to  all  CGM  users. 

24.  TOP  and  CALS  both  say  that  Metafile  Defaults  Replacement  shall 
not  be  partitioned.  TOP  further  says  that  no  element  within  MDR 
shall  be  partitioned.  Assessment:  CALS  should  say  this  as 
well.  It  will  be  put  into  the  next  revision.  TOP  should  keep 
the  specification. 

25.  TOP  has  a  section  on  metafile  transfer  using  FTAM  and  MHS. 
Assessment:  this  was  not  appropriate  for  the  current  CALS 
environment.  There  is  no  problem  with  TOP  retaining  the 
specification. 
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“USER  COLLABORATION:  A  Proposal  to  Improve  the  Efficiency  of  Information  Technology 
StandaRfs  Saiection  for  Government  vrti  Industry* 

Prepared  for  Or.  M.  McGrath.  Director.  CALS  Office 

by  the  MAP/TOP  Division  of  The  Information  Technology  Requirements  Council 
EXECUTIVE  SUMMARY 

The  voluntary  standards  process  In  the  United  States  has  bean  changing  over  the  last 
several  years.  One  of  the  more  noticeable  changes  has  been  the  involvement  of  the  user 
community  in  what  has  been  a  vendor  dominated  activity.  This  user  push  is  based  on 
user  requirements  to  apply  information  technology  to  achieve  oompedtive  advantage  in  a 
world  market  The  government  as  a  user  shares  the  same  need  as  industry.  Both  groups 
need  to  be  able  to  easily  share  useful  information  eiectrorticaliy  within  and  between 
organizations  on  a  global  scale.  Botfi  groups  need  solutions  that  are  cost  effective,  that 
can  evolve  to  meet  changing  needs  and  that  wiH  preserve  the  existing  investmem  made  in 
oomputing  equipment  and  applications  software.  This  csmot  be  done  without  the 

of  strategicjstandards.  There  is  a  genuine  concern  tod^  that  the  United 
States  is  falling  behind  Europe  and  Japan  in  developing  and  promoting  the  use  of 
intemationai  standards. 

Today,  there  exists  two  or  more  separate  processes  for  this  user  push.  One  process 
focuses  on  industry  users,  the  others  on  the  govemmenfs  needs.  This  paper  proposes  a 
collaboration  of  government  and  industry  to  pursue  the  mutual  objectives  of  the 
information  technology  ’user*. 
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Slnc«  ttw  Mriy  '80*a.  the  United  States  voluntaiy  standards  process  for  information 
tecftnology  standards  has  bean  changing.  A  number  of  issues  provided  the  catalyst  for 
these  chariges. 


The  development  of  base  standards  was  vendor  dominated.  Users  and  user 
requirements  were  noticeably  absent  in  the  process. 

The  government,  both  dviJian  and  military  agendas  were  being  pushed  by 
congress  to  use  the  voluntary  Industry  standards  instead  of  developing  their  own. 

The  development  cyde  for  standards  and  for  conforming  products  took  way  too 
long. 


Products  developed  to  these  base  standards  ffaquentiy  dd  not  work  together. 

(X.2S  is  a  good  example). 

The  changes  that  began  to  occur  as  a  result  of  these  issues  are  for  the  most  part  very 
positive. 

NBS.  now  NIST  InMatad  a  series  of  workshops  to  provide  an  open  forum  for 
vendor  implementation  agreements.  These  agreements  •  the  refining  of  a  stable 
base  standard  *  were  a  necessary  step  if  compatfote  products  were  to  be  built 

The  MAP/TQP  User  Group  was  formed.  The  primary  ot^ective  of  this  multi- 
industry  user  group  is  to  accelerate  the  availabinty  of  information  technology 
standards  based  products  that  meet  real  user  needs.  Activities  indude  a 
consensus  based  process  to  define  core  sets  of  user  requirements,  carry  forward 
those  requirements  into  appropriate  activities,  including  the  NIST  agreements 
process,  and  document  the  final  results  in  spedfications  that  can  be  used  to 
procure  systems  that  meet  the  established  requirements. 

commwt:  Various  terms  have  been  used  to  define  this  user  fvocess:  pmfillng, 
tailoring,  and  flavoring  are  all  terms  used  to  mean  the  reduction  of  a  general  bsse 
standard  into  a  more  implementable  pacification. 

The  Comormion  far  Open  Systems  (COS)  was  established  to  develop  the  tests 
necessary  for  testing  and  certifying  products  that  are  compliant  to  the  standard 
specifications. 

The  Gavemmern  QSl  Ueer  Graun  was  formed  under  the  auspices  of  the  Department 
of  Commerce.  This  group  generally  performs  a  similar  set  of  functions  as 
MAP/TOP  for  the  goyernment  The  spedflcaiion  produced  becomes  a  Federal 
Information  Processing  Standard  that  is  used  as  a  procuremem  specification.  The 
currem  version  QOSlP,  version  1,  RPS  146  Is  a  compatible  subset  of  the 
MAPrrOP  spedfication  work. 

Itlfl.,DQD  CALS  Program  was  initiated  as  a  major  program  by  the  Oepartmem  of 
Defense.  This  activity  is  broader  in  scope  than  MAP/TOP  and  GOSIP  it 

covers  areas  beyond  the  one  of  accelerating  standards  conforming  products.  CALS 
is  intended  to  accelerate  the  use  of  electronie  information  exchange  between 
military  agendas  and  their  suppliers  arfo  contractors.  One  aspect  of  the  CALS 
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pregram  does  (bcus  on  tho  docufnontadm  of  MItSPEC  standanfs  tar  data 
knarefiangt,  again  a  tailoring  of  a  basa  ^andard  to  moot  ttia  mffitaiy  agoncy  usar 
raquiramants.  In  addition.  CALS  win  usa  RPS  146  to  dafina  tha  natworfc 
products  and  application  sarvicas  to  axcOanga  information  in  tha  tarmats 
spadllad  by  tba  CALS  intarcbange  standards. 


Tba  MAP/TOP  activity,  tha  GOSIP  activity,  and  parts  of  tha  CALS  activity  ail  hava 
common  eiamants 

AD  thraa  ara  usar  driven  activities. 

All  tacus  on  tha  usa  of  information  technology  standards  produced  by  the 
voluntary  standards  process. 

AD  groups  define  user  requirements,  or  assume  a  knovviadga  of  usar 
requirements,  tailor  or  profila  basa  standards  to  meat  those  raquiramants.  and 
document  tha  results  in  specifications  used  to  procure  systems. 

AU  groups  are  attempting  to  accelerate  the  availability  of  compliant  products. 


The  results  of  aD  of  these  activities.  NIST.  MAP/TOP.  COS^  GOSIP.  «id  CALS,  ara 
positive.  Tha  output  of  aU  thraa  user  group  activitiM.  ara  reasonably  oonsistanL  Usar 
input  is  made  into  tha  standards  process  arta  tha  agraamants  proofe-  Output  of  tha 
agreements  process  is  the  basis  tar  the  user  specifications,  and  a  trial  test  activity  is 
underway  with  a  good  start  on  the  tests  necessary  to  certify  products  as  MAP.  TOP  and 
GOSIPoompiiant 


THE  PROBLEM 

From  a  user  perspective,  tha  currem  paraliei  usar  activtties  present  some'  problems. 

1  )  Because  there  ara  three  separate  groups,  each  establishing  requirements  and 
publishing  specifications,  few  vendors  or  users  not  involved  in  aD  tha  procassas 
understand  that  tha  work  is  oompiamentary  and  oompatibla  •  at  least  today.  Tha 
result  of  this  confusion  is  product  delay.  Vendors  doni  know  which  specifications 
to  use  and  users  doni  know  what  to  buy. 

2 )  Thera  is  no  astabOshad  process  to  keep  future  work  aligned. 

3  )  The  process  is  InafficianL  Multiple  committaas  are  addressing  tha  same  »siuts, 
achaduias  an  dHtarent  and  extra  steps  an  inserted  in  the  process  to  harmonize 
tha  results  and  make  them  technicaliy  consistenL 

4 )  The  muitipla  committee  process  tarcas  sUOs  dDution  affecting  the  quaDty  of  tho 
output. 

5 )  While  the  MAP/TOP  committees  an  open  to  everyone  and  att  work  is  ri*iRrihiited 
tor  oommont  tha  govamment  spadficaiion  davaiopmant  is  dona  in  dosed 
committee  with  only  tha  final  work  published  for  commam.  This  diffennea  in 
process  makas  'harmonizing*  difficult. 


6 )  Wont  of  ail*  as  usara  wa  ara  not  lavaraging  and  pushing  tha  marfcat  tha  way  wa 
vnyfy  as  a  comhinad  tarca.  As  a  unifiad  effort,  products  would  ba  availabla  faster 
and  at  iowar  oost  to  avarybody. 

PROPOSED  SOLUTION 

Tha  proposad  solution  consists  of  threa  areas  of  collaboration:  planning,  specification 
davafopment.  and  Joint  promotion. 

Plannlna 

Each  group  has  ona  or  more  activitias  planning  new  work  items  in  tha  information 
technology  standards  area.  This  planning  ^:po»s  to  ba  dona  on  a  yaaily  basis.  To 
improva  tha  process,  a  recommended  l^icai  flrst  step  is  to  form  a  joim  planning 
activity  which  would  meat  at  iaast  annually. 

Each  group  would  coma  prepared  with  its  work  items 

Work  would  ba  split  into  common  acUvitias  and  organization  uniqua  activities. 

Tha  schadulas  for  common  activitias  would  ba  raoondiad. 

Shared  oommitteas  would  ba  formed  to  address  common  acdvittes  identified. 

Each  organization  would  pursue  their  uniqua  activitias  indapandantty. 

Sneeiffestlon  PaYeloameill 
Tha  joim  or  shared  committees  would: 

Compile  requiramants  to  meat  needs  of  government  and  iridustry. 

idemify  any  special  requirements  that  would  prevent  development  of  oost 
effectiva  products  •  hap^futfy  these  are  a  tew  isoUaad  cases. 

Reach  agreemem  on  how  spectai  requirements  are  to  ba  handlad. 

Carry  forward  consolidated  requirements  into  other  appropriate  forums. 

Develop  common  text  to  ba  used  in  all  spadfications. 

Distribute  agreed  upon  common  text  to  ba  used  in  all  spadfications  for  public 
oemmant  and  review.  This  can  ba  dona  in  ona  of  two  ways: 

1 )  Batiti  group  conducts  independam  comment  and  review  process. 

2 )  A  combined  oommam  and  review  process  is  used. 

Modify  text  based  on  valid  comments. 

Each  group  would  than  proceed  to  publish  specifications  using  their  normal  procedures 
and  processes,  using  common  text  and  cross<referendng  each  other. 


I 
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Pfamatlan 

In  ord^r  10  inauro  that  maximum  banefit  and  impact  ia  achiave  ^  joim  promotion  should 
ba  piannad.  ActtvMaa  oouid  induda: 

joint  press  relaasaa 
shared  sassions  at  oonterancas 

cross*refarenca  othar  groups  activitias  whanavar  possibla 

hold  Joim  oontoreneas 

hoid  joim  damonstrations 

Jointly  publish  papars  and  artidas 

AOMINISTRATION  OF  JOU^  ACTIVmES 

Tha  options  tor  hosting  thasa  Joint  activitias  are  savaraL 

NIST 

OGD 

ITRC 

MAP/TOP 

othars 

imc  was  astabll^ad  to  promota  tha  partnaring  of  govarornam  and  Industry  in  tha 
pursuit  of  tha  basic  objac^a  that  all  thraa  of  tha  groups  undar  discussion  share  today  • 
tha  accataration  of  tha  davaiopmant  and  accaptanca  of  Intormation  tadmoiogy  standards 
and  tha  availability  of  a  wida  choica  of  tastad  and  compUam  products  that  maat  usar 
rsduiramants. 

rmc  is  tharetora  rscommandad  as  tha  organization  to  administar  this  process.  Howavar, 
any  reasonabla  aitamativa  that  affsctivaiy  addrassas  tha  problams  outiinad  in  this  paper 
would  ba  acceptable. 

RESULTS 

If  this  proposal  is  adad  upon,  the  results  would  ba: 

A  dramatic  acealaration  of  tha  availability  of  products  that  conform  to 
information  technology  standards. 

Batter  choica  of  products  tor  all  users 

Improved  reliability  and  compatibility 

Batter  fundionallty 

Lower  cost 

Elimination  of  tha  currem  confusion  (hat  government  and  industry  are 
indapandantfy  corrvarglng  on  diffaram  sms  of  standards. 


Ainora  •ffidant  process  to  assure  oompatSiie  products  that  meet  aU  user 
requirements 

BImination  of  duplicate  committees 

Setter  utUIzatlon  of  scarce  resouicas  to  pursue  user  goals 

EHmination  of  extra  steps  to  'harmoniza*  results  of  parallel  processes 

More  cost-eftoctlve.  timely  approach  to  accomplish  shared  goais. 

A  collaboration  that  wiO  encourage  other  United  States  users  to  join  this  process 
instead  of  starting  up  new  activities  which  win  create  addmonai  confusion. 

A  partnership  that  wM  allow  the  United  States  to  more  effactlveiy  leverage  its 
interests  in  international  standards  development  and  aUow  us  to  more  effactlveiy 
compete  in  the  world  community. 
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1.  INTRODUCTION 


This  is  the  final  report  for  FY89  in  support  of  CALS  SOW  Task 
4.1.4,  which  states :  Continue  to  define  CGM  extensions  needed  to 
support  CALS.  Support  identified  extensions  through  the 
registration  process. 

This  task  was  further  subdivided  into  four  subtasks  as  specified 
below: 

1.  Lines  and  Hatches: 

Define  requirements  for  lines,  hatches  and  text  font 
usage  to  support  automated  publications.  Identifica¬ 
tion  of  requirements  will  be  based  on  applicable  MIL- 
STD's  and  existing  commercial  practice. 

2.  Text: 

Develop  and  define  a  new  text  Graphical  Display 
Primitive  (GDP)  and  associated  escapes  (to  implement 
attributes)  that  can  fully  implement  the  portions  of 
the  model  of  ISO  DP  9541  which  are  appropriate  for 
graphics  standards.  Extensions  to  the  "CGM 

Environment”  compatible  with  the  ISO  font  description 
and  transfer  work  shall  also  be  developed. 

3.  Named  Items  and  Symbol  Libraries: 

Develop  extensions  to  CGM  to  define  collections  of 
graphical  primitives  as  macros  or  symbols. 

4.  Sponsorship  of  Registration  Proposals: 

Negotiate  any  required  changes  with  the  X3H3  committee. 
Following  ASC  X3H3  approval,  sponsor  each  proposal 
through  the  ISO  registration  process,  responding  as 
necessary  to  requests  for  changes  and  clarification. 
For  previously  proposed  items,  continue  support  through 
the  registration  process. 


1.1  Progress  to  date 

In  the  area  of  CGM  lines  and  hatches,  no  additional  requirements 
for  specific  lines  or  hatches  were  generated  during  this  fiscal 
year.  This  report  provides  the  rationale  used  to  develop  the 
previously  defined  user-defined  line  styles  and  defines  the 
requirements  for  a  user-defined  hatch  style.  A  registration 
proposal  is  included  for  a  general  fill  that  can  meet  the  needs 
of  a  "user-defined  hatch."  This  report  also  identifies  the  need 
for  support  for  closed  figures.  Since  Closed  Figure  support  is 


included  in  CGM  Addendum  1,  no  additional  proposals  were 
developed,  as  those  in  Addendum  1  are  suitable  lor  CALS  use. 

In  the  area  of  text,  this  report  provides  extensive  analysis  and 
requirements  development.  A  phased  approach  is  taken,  with  both 
near  term  and  future  strategies  being  considered.  The 
relationship  of  text  font  to  character  set  is  explained  and  the 
difficulty  of  registering  new  character  sets  is  described.  The 
naming  of  "fonts"  is  described  and  various  approaches  to  what 
should  be  "named"  are  compared  and  the  difficulties  described. 
The  architecture  derived  is  a  significant  contribution  towards 
achieving  compatible  usage  of  font  resources  among  various 
presentation  processes  (including  CGM-based  computer  graphics 
systems,  SPDL,  ODA,  and  SGML  systems) .  No  CGM  extensions  are 
proposed  in  the  area. 

In  the  area  of  named  items  and  symbol  libraries  this  report 
develops  a  set  of  requirements  and  provides  extensive  analysis  of 
competing  approaches.  As  with  text,  a  phased  approach  is  taken, 
with  both  near  term  and  future  strategies  being  considered.  The 
approach  taken  is  compatible,  in  the  long  run,  with  the  approach 
to  text.  It  will  allow  the  eventual  definition  of  font  and 
symbol  resources  that  are  compatible  as  possible. 

In  the  area  of  sponsorship  of  registration  proposals  the  work 
done  is  described.  There  were  a  set  of  comments  on  previous 
proposals  that  were  "referred  back  to  the  proposer,"  and  changes 
to  these  proposals  based  on  the  comments  have  been  made.  At  the 
Nashua  X3H3  meeting  (25-29  September  89)  modifications  to  a 
previous  set  of  proposals  that  allowed  them  to  pass  X3H3  ballot 
were  agreed  on.  The  final  versions  of  these  modifications  are 
also  included  here. 


1.2  CGM  Extension  Philosophy 

There  are  several  important  assumptions  that  compose  the 
philosophy  of  CGM  extensions.  These  have  been  implicit  in  the 
CALS  work  to  date,  but  should  be  formally  documented  to  help 
others  understand  this  work.  These  assumptions  are: 

1)  Whenever  possible,  adopt  extensions  directly  from  other 

standards  or  de-facto  standards  that  reflect 

predominant  commercial  practice.  This  includes 

adopting  flawed  and  non-optional  solutions  where 
operability  is  not  degraded  and  compatibility  is 
enhanced. 

2)  Any  CALS  CGM  should  be  interpretable  by  a  non-CALS 
system  in  a  predictable  way. 
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3)  Invention  of  new  primitives  and  concepts  should  be 
avoided  if  an  existing  CGM  element's  meaning  can  be 
reasonably  modified  to  meet  CALS  requirements.  (This 
maximizes  the  extent  to  which  non-CALS  interpreters  can 
interpret  CALS  CGM  files.) 

4)  Make  only  the  minimal  extensions  required  for  CALS 
rather  than  more  general  ones  useful  to  other 
application  areas. 


2.  LINES  AND  HATCHES 

Based  on  review  of  MIL-STDs  in  hand  and  commercial  practice,  no 
additional  specific  line  styles  or  hatch  styles  have  been  able  to 
be  identified  as  required  for  CALS,  other  than  the  user-defined 
hatch  style  as  defined  below. 

Several  "line-types"  have  been  identified  as  needed  in  what 
appear  to  be  a  limited  number  of  cases  in  drawings  constructed 
according  to  various  MIL-STDs.  Since  there  are  not  enough 
examples  of  CALS  document  practice  to  judge  the  universality  of 
many  of  these,  the  approach  adopted  has  been  to  implement  those 
of  them  that  cannot  be  done  with  the  existing  user-defined  line 
type  proposal  by  using  a  closed  figure  construct.  A  further 
argument  against  registering  additional  lines  and  hatches  at  this 
time  is  that  the  arguments  for  them  derive  primarily  from 
engineering  drawing  exchange,  not  technical  illustration  exchange 
format.  The  CGM  is  not  yet  an  allowable  exchange  format  for 
engineering  drawings  in  CALS.  For  this  reason,  a  set  of 
additional  graphical  constructs  are  defined  below  that  are  needed 
CGM  extensions  to  meet  CALS  requirements.  These  are  adopted  from 
CGM  Addendum  1. 


2.1  General  Approach  to  "Hatches" 

For  reasons  explained  in  previous  CALS  reports,  NIST/NCSL  has 
adopted  an  approach  of  meeting  CALS  requirements  for  treatment  of 
the  interiors  of  filled  objects  by  slightly  extending  the  concept 
of  "hatch"  to  allow  irregular  fills.  Although  the  ANSI  X3H3 
committee  was  convinced  of  the  appropriateness  of  this  approach, 
US  delegates  were  not  able  to  convince  their  ISO  counterparts  at 
the  ISO  level  registration  meeting  held  earlier  this  year. 
Consequently,  several  proposals  for  hatch  styles  were  not 
accepted  for  registration.  These  were  essential  for  CALS  use. 
Fortunately,  they  are  already  part  of  the  CALS  CGM  AP 
(Mil-D-28003) . 

No  change  in  the  approach  is  planned  for  several  reasons: 
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1)  The  ISO  objections  were  based  on  a  narrow 

interpretation  of  the  definition  "hatch"  as  defined  in 
GKS. 

2)  The  only  alternative  to  expanding  the  definition  of 
hatch  is  to  define  a  new  "interior  style"  different 
from  the  presently  allowed  hollow,  solid,  pattern, 
hatch,  and  empty.  This  is  difficult  to  do  by 
registration  alone  since  the  list  of  interior  styles 
cannot  itself  be  extended  through  registration. 
Nonetheless,  a  set  of  registration  proposals  is  being 
submitted  with  this  report  to  allow  a  general  fill. 
The  requirements  to  be  satisfied  with  "extended  hatch" 
can  be  met,  although  not  optionally,  with  this  general 
fill.  It  is  included  to  meet  certain  technical 
illustration  requirements  that  cannot  be  met  with 
predefined,  registered  hatch  patterns. 

3)  In  the  long  term  new  Application  Programmer  Interface 
standards  (such  as  revisions  to  GKS  and  PHIGS)  and  CGM 
extensions  work  is  expected  to  validate  the  need  for  a 
new  alternative  interior  style  treatment.  This  style 
could  be  added  to  the  list  of  allowable  interior 
styles,  or  the  concept  of  hatch  could  be  extended. 


2.2  User-defined  "Hatch"  Style 

It  is  evident  that  there  are  special  circumstances  where  there 
will  be  areas  whose  interiors  must  be  "filled"  with  a  more  or 
less  regular  graphical  "pattern."  The  more  common  of  these  have 
been  previously  identified  and  proposed  for  registration.  Less 
common  and  more  specialized  ones  are  needed  nonetheless, 
especially  in  technical  illustrations,  and  some  mechanism  must  be 
found  for  accommodating  them.  Since  resulting  drawings  are  not 
revisable,  these  interior  treatments  cannot  be  "rendered"  by 
drawing  them  with  individual  graphical  primitives.  This  is 
because  the  primitive  scale  is  the  drawing.  A  further  argument 
for  their  use  is  the  additional  compactness  that  results  from 
describing  a  repeating  graphical  "pattern"  only  once. 

It  takes  only  a  brief  review  of  the  hatch  styles  thus  far 
proposed  for  registration  to  realize  that  no  restrictions  can  be 
placed  on  the  allowable  graphical  primitives  that  can  define  the 
"pattern"  in  such  a  filled  area.  In  particular,  allowing  only 
traditional  straight  lines  in  such  a  user-defined  hatch  is  not 
adequate.  Similarly,  raster-like  patterns  are  inadequate.  What 
is  required  is  a  concept  similar  to  what  Page  Description 
Languages  (PDLs)  call  "ink,"  whereby  a  "picture"  can  be  drawn 
using  any  valid  operators  and  repeated  on  a  regular  basis 
throughout  the  area  to  be  filled.  Consequently  the  Generalized 
Fill  escape  proposed  with  this  report  will  allow  any  valid 
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picture  to  be  used  as  its  "fill  pattern."  Existing  reference 
points  and  sizing  information  for  fill  patterns  can  be  used  to 
place  and  size  the  filling  picture. 


2.3  Other  Required  Graphical  Elements 

Several  graphical  elements  are  required  both  to  allow 

user-defined  edges  and  lines  and  to  meet  require’rc.its  identified 
for  defining  closed  figures  by  composite  curves.  All  of  these 
can  be  based  on  elements  defined  in  the  CGI,  so  little 

controversy  is  expected  over  their  definitions.  During  the  last 
year,  CGM  Addendum  1,  which  incorporates  these  CGI  facilities, 
has  advanced  far  enough  so  that  adopting  the  following  elements 
into  the  CALS  AP  can  be  recommended  rather  than  submitting 
duplicate  proposals  through  the  registration  process: 

1)  BEGIN  FIGURE 

2 )  END  FIGURE 

3 )  CONNECTING  EDGE 

4 )  NEW  REGION 

These  escapes  are  used  to  construct  closed  figures  as  follows. 
BEGIN  FIGURE  starts  the  accumulation.  Subsequent  graphical 
drawing  primitives  or  GDPs  (not  the  limited  set  allowed  in  the 
CGI  proposal)  are  accumulated  into  the  figure.  This  process  is 
stopped  by  an  END  FIGURE  escape.  The  CONNECTING  EDGE  escape 
controls  whether  edges  are  drawn  connecting  subsequent  primitives 
that  might  not  otherwise  connect.  The  NEW  REGION  escape  causes 
the  sub-figure  being  accumulated  to  be  closed  and  a  new 
sub- figure  to  be  started. 

In  addition  NIST/NCSL  does  not  perceive  requirements  for  clipping 
to  arbitrary  regions  within  CALS.  A  general  user-defined  "fill" 
can  create  most,  if  not  all,  the  graphical  effects  that  clipping 
to  arbitrary  regions  can  achieve.  In  the  remaining  cases,  (if 
any)  the  burden  is  best  placed  on  the  generator  to  perform  the 
clipping,  rather  than  on  all  interpreters.  The  generating  system 
must  already  be  able  to  do  this  kind  of  clipping  since  it  must 
"preview"  the  CGM  files  or  the  local  drawings  they  are  derived 
from.  There  are  further  important  arguments  for  a  generalized 
"fill"  over  clipping  to  arbitrary  boundaries: 

a)  Interpreters  that  cannot  clip  to  arbitrary  boundaries 
would  get  a  very  wrong  picture,  with  the  objects  being 
clipped  spilling  over  onto  other  areas;  in  the 
generalized  fill  approach,  the  correct  objects  would 
still  be  drawn  and  appropriate  defaults  could  cause  it 
to  still  look  about  right. 
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b)  Usually  it  is  not  desirable  to  have  the  "insides"  of 
arbitrary  filled  areas  transform  as  the  picture  is 
revised;  the  "clipping  to  arbitrary  boundaries 
approach"  cannot  prevent  this. 


2.4  Color  Support 

Some  color  models,  such  as  CMYK,  are  device  and  printing 
process-dependent.  (The  amount  of  "K",  usually  "black",  that  is 
applied  depends  on  printer  ink  characteristics  and  on  mechanical 
or  physical  reasons.  "K"  is  used  to  achieve  highly  saturated 
areas  of  black,  in  lieu  of  more  expensive  cyan,  (C) ,  yellow  (Y) , 
and  magenta  (M)  inks,  or  to  prevent  paper  from  getting  too  wet.) 
Therefore  they  are  not  suitable  for  device-independent 
interchange.  Others,  such  as  CIE  models,  provide  a  degree  of 
precision  and  device-independence  that  is  pointless  for  CALS 
applications,  and  can  be  avoided  (for  CALS  purposes)  by  simply 
using  calibrated  exchange  based  on  an  RGB  model.  Besides,  most 
CALS  technical  illustrations  will  be  monochrome  or  gray-level. 

Industry  practice  today  is  to  exercise  precise  color  control  only 
for  final  form  documents  and  then  only  as  represented  in  four 
color  separates  and  only  within  a  single  system.  The  following 
typical  list  of  steps  shows  the  nature  of  the  complex, 
device-dependent  processing  involved; 

1)  Producing  three  separate  RGB  bitmaps  representing  the 
picture. 

2)  Transforming  these  bitmaps  through  a  complex, 

system-dependent  process  into  CMYK  bitmaps.  These 
transforms  correct  for: 

a)  device  calibration; 

b)  different  color  gamuts  in  the  display  and  printing 
devices; 

c)  gray  balance,  gray  component  replacement,  and 
production  of  a  black  separate. 

3)  Production  of  a  Cromalin  proof  (hard-)  copy  from  the 
separates  to  provide  to  the  printer. 

Therefore,  support  for  additional  colour  models  is  not  required. 
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3.  TEXT 


There  are  many  issues  to  address  in  extending  the  CGM  to  support 
the  text  requirements  for  CALS.  After  providing  necessary 
background  information  and  reiterating  the  text  requirements 
developed  previously,  these  issues  are  defined  and  addressed  in 
turn.  The  major  issues  are: 

1)  What  character  sets  are  required  for  CALS? 

2)  How  should  character  sets  be  associated  with  the  glyphs 
in  a  font? 

3)  What  should  the  contents  of  a  "font  list"  be? 

4)  What  "names"  should  be  registered  for  fonts? 

5)  What  extensions,  if  any,  are  needed  to  the  CGM  text 
model  to  support  use  of  DIS  9541  font  resources? 

6)  To  what  extent  should  font  substitution  information  be 
supported  in  the  CGM? 

7)  Are  user-defined  fonts  required?  If  so,  what  approach 
should  be  taken? 

Subsequent  paragraphs  below  address  each  of  these  issues  in  turn. 


3 . 1  Introduction 

This  subsection  provides  a  condensed  version  of  background 
information  from  standards  in  the  areas  of  computer  graphics, 
codes  and  character  sets,  and  office  systems.  Knowledge  of  this 
material  is  necessary  to  understand  the  concepts  presented 
elsewhere  in  this  report.  Throughout,  standards  are  referred  to 
by  their  ISO  rather  than  ANSI  or  FIPS  designators.  Most  of  the 
indicated  standards  have,  or  will  have,  both  ANSI  and  FIPS 
counterparts . 


3.1.1  Codes  and  Character  Sets 

The  first  standard  concerning  coded  character  sets  was  ISO 
646-1973.  It  defined  a  basic  7  bit  character  set  designed  to  be 
specialized  for  national  use  by  assigning  country-specific  values 
to  certain  national  symbols,  such  as  the  currency  symbol.  ANSI 
X3. 4-1977  specialized  ISO  646  for  US  use  as  the  familiar  "ASCII" 
character  set.  ISO  2022-1986  defined  an  extensible  framework 
whereby  both  7  and  8  bit  character  sets  could  be  built  from 
smaller  components  called  "C"  sets  and  "G"  sets  of  94  or  96 
characters  ("C"  for  control  and  "G"  for  graphic) . 
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These  C  and  G  sets  can  be  switched  in  and  out  of  the  active  code 
table  through  a  process  known  as  code  extension.  In  this 
technique,  each  C  set  or  G  set  is  identified  by  a  unique  escape 
sequence.  Escape  sequences  can  be  registered  in  the 
International  Register  of  Coded  Character  Sets  to  be  Used  with 
Escape  Sequences  or  can  have  a  privately-understood  meaning.  For 
example,  the  ASCII  "G”  set  is  invoked  as  the  primary  graphics 
character  set  (called  the  GO  set)  by  the  sequence  "ESC  02/08 
04/02.”  Appendix  A  contains  the  descriptions  of  both  the  ASCII 
character  sets  and  the  Latin  alphabet  No.  1  character  sets  from 
this  register. 

More  recently,  ISO  6937-1983  has  consolidated  previous  standards 
and  defined  general  techniques  for  the  use  of  coded  character 
sets  in  text  communication.  Among  the  subsequent  standards  based 
on  6937  is  ISO  8859  which  defines  8-bit  single  byte  coded  graphic 
character  sets.  Part  1  of  ISO  8859  defines  Latin  alphabet  No.  1 
by  consolidating  the  two  G  sets  from  ISO  646  and  the  registered 
version  of  Latin  alphabet  No.  1.  Appendix  A  contains  a  copy  of 
the  pages  of  ISO  8859-1  that  define  Latin  alphabet  No.  1. 

The  codes  and  character  sets  in  all  computer  graphic  standards 
today  are  based  on  the  above  standards.  These  standards  and  the 
coding  techniques  embodied  in  them  were  developed  by  ISO/IEC 
JTC1/SC2  and  are  based  largely  on  telecommunication  requirements. 
They  are  less  than  adequate  for  describing  and  coding  typographic 
quality  text. 

ISO  8879  (SGML)  takes  a  somewhat  different  approach  to  character 
sets.  Beyond  use  of  a  subset  of  the  basic  "ASCII”  characters 
(referred  to  by  their  decimal  equivalents  in  Figure  1  of  ISO 
8879)  additional  "character  entity  sets”  are  defined  in  Appendix 
A.  Also  an  ISO  646/ISO  2022  "multicode”  structure  allows  the  use 
of  standard  GO  and  G1  national  character  sets. 


3.1.2  DIS  9541,  Font  Information  Interchange,  and  ISO  10036, 
Procedures  for  Registration  of  Glyph  and  Glyph  Collection 
Identifiers 

These  standards  define  an  alternative  scheme  for  dealing  with 
"codes  and  character  sets.”  The  first  step  in  this  process  is  to 
separate  the  "symbol"  being  represented  from  the  "code"  used  to 
identify  it  in  transfer.  The  term  glyph  is  defined  to  replace 
the  overused  term  character.  A  glyph  is  simply  an  identified 
abstract  graphical  symbol  independent  of  any  actual  image.  The 
term  glyph  collection  is  a  precise  substitute  for  the  loosely 
defined  term  font.  Glyphs  and  glyph  collections  are  registered 
and  assigned  identifiers  according  to  the  procedures  defined  in 
ISO  10036.  Appendix  B  contains  a  somewhat  out-of-date  sample 
from  a  prototype  glyph  register  showing  the  same  accented  Latin 
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characters  described  in  Latin  alphabet  No.  1.  It  also  contains 
sample  forms  used  for  registering  glyphs. 

The  font  information  interchange  architecture  and  format  defined 
in  DIS  9541  is  centered  on  an  object  called  a  font  resource.  A 
font  resource  is  a  collection  of  glyph  representations  together 
with  descriptive  information  and  font  metrics  which  are  relevant 
to  the  collection  as  a  whole.  A  font  resource  consists  of: 

1)  Descriptive  attributes 

2 )  Font  metrics 

3 )  Glyph  descriptions 

-  Glyph  metrics 

-  Glyph  shapes 

Some  of  the  information  in  a  font  resource  depends  on  the  "path” 
along  which  the  text  progresses  as  it  is  written.  This  is  called 
the  writing  mode  in  DIS  9541.  Thus  a  single  font  resource  may 
contain  several  sets  of  font  metrics  and  glyph  metrics,  one  for 
each  supported  writing  mode. 

The  complete  set  of  font  information  is  not  needed  for  all 
purposes,  so  the  interchange  format  defined  in  DIS  9541 
identifies  named  subsets  that  incorporate  each  major  class  of 
information.  These  subsets  are: 

1)  Minimum  Font  Description  Subset 

2)  Minimum  Font  Metric  Subset 

3)  Minimum  Glyph  Description  Subset 

4)  Minimum  Glyph  Metric  Subset 

5)  Minimum  Glyph  Shape  Subset 

The  set  of  information  in  each  subset  is: 

1)  Minimum  Font  Description  Subset 

o  Font  resource  name  (e.g.  IS0954 1/Helvetica/Bold) 
o  Source  name 

o  Font  family  name  (e.g.  Helvetica) 

o  Posture  (upright,  oblique,  back  slanted  oblique, 

italic,  back  slanted  italic,  or  other) 
o  Weight  (ultra  light,  extra  light,  light,  semi 

light,  medium,  semi  bold,  bold,  extra  bold,  or 
ultra  bold) 

o  Proportionate  width  (ultra  condensed,  extra 

condensed,  condensed,  semi-condensed,  medium, 
semi  expanded,  expanded,  extra  expanded,  or  ultra 
expanded) 

o  Design  group  (e.g.  serif) 

o  Structure  (solid,  outline,  inline,  shadow,  or 
patterned) 
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o  Design  size  (the  body  size  at  which  the  resource 
was  designed  to  be  used,  in  mm.) 
o  Minimum  size 

o  Maximum  size 

2)  Minimum  Font  Metric  Subset  (repeated  for  each  writing 
mode) 

o  Writing  mode  (left  to  right,  bottom  to  top,  right 
to  left,  or  top  to  bottom) 
o  Average  lower  case  escapement 
o  Average  capital  escapement 

o  Tabular  escapement 

3}  Minimum  Glyph  Description  Subset  (repeated  for  each 
glyph) 

o  Glyph  structured  name  (see  discussion  below) 

4)  Minimum  Glyph  Metric  Subset  (repeated  for  each  glyph, 
unless  the  font  is  fixed  pitch) 

o  X  position  point 

o  Y  position  point 

o  X  escapement  point 

o  Y  escapement  point 

5)  Minimum  Glyph  Shape  Subset  (repeated  for  shape 
representation  technology  supported  by  the  font 
resource) 

o  Glyph  shape  representation  technology  (bitmap, 
straight-line,  outline,  circular  outline,  conic 
outline,  Bezier  outline,  or  mixed) 
o  Glyph  shape  (  a  "code-body”  defining  the  shape;  it 
is  assumed  that  CGM  elements,  or  primitives  that 
can  be  easily  translated  to  CGM  elements  will  be 
used) 

Certain  additional  information  is  included  only  in  the  complete 
font  resource  and  is  not  in  any  subset.  Important  information  in 
this  category  includes: 

o  Device- independent  font  resource  name  (a  font  resource 

containing  this  one,  together  with  other  resources  that 
use  different  shape  description  technologies) 
o  Proprietary  data  indicator  (e.g.  copyright  and 
trademark  citations) 

o  Typeface  name  (e.g.  Helvetica  Bold  Italic) 

o  Glyph  complement  (identification  of  the  glyphs  in  the 
font) 

o  Ligature  table 
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o  Minimum  feature  size 

o  Forward,  left,  backward,  and  right  extents 

o  etc . 

Each  glyph  will  have  a  structured  name  by  which  it  will  be 
referenced  in  DIS  9541.  The  structured  name  will  be  composed  of 
the  glyph  description,  as  illustrated  in  the  sample  in  Appendix 
B,  preceded  by  other  identifiers  in  a  hierarchical  fashion.  For 
example,  the  "Grave  A"  that  shows  up  in  Latin  alphabet  No.  1  in 
position  00/04  and  is  called  "CAPITAL  LETTER  A  WITH  GRAVE  ACCENT" 
and  with  bit  combination  12/00  in  ISO  8859-1  might  have  a 
structured  name  of  "IS010036/ACCENTED  LATIN  CHARACTERS/GRAVE  A". 

One  issue  that  has  yet  to  be  settled  is  the  precise  form  of  the 
"code-body"  that  will  describe  the  glyph  shapes.  Several 
alternatives  have  been  mentioned: 

1)  line  segments 

2)  conics 

3)  Bezier  curves 

4)  bitmaps 

The  ultimate  usability  of  font  resources  by  computer  graphics 
standards  hinges  upon  the  adoption  of  a  shape  description 
technique  that  is  readily  translatable  into  CGM/CGI-like 
graphical  primitives  and  attributes. 


3.1.3  Character  Sets  and  Fonts  in  the  CGM 

The  metafile  descriptor  of  each  CGM  file  can  contain  a  FONT  LIST 
and  a  CHARACTER  SET  LIST.  A  font  list  is  a  set  of  strings  that 
contain  the  names  of  all  fonts  used  in  the  file.  These  names  may 
be  private  or  registered.  The  font  list  also  associates  an  index 
with  each  font.  The  character  set  list  declares  the  character 
sets  that  are  used  in  text  primitives.  It  also  assigns  an  index 
to  each  character  set.  A  CHARACTER  CODING  ANNOUNCER  element 
informs  the  interpreter  of  the  sort  of  code  extension 
capabilities  that  may  be  required. 

The  CALS  CGM  AP  (MIL-D-28003 )  restricts  these  values  as  follows: 

FONT  LIST:  up  to  four  names  from  a  basic  list  of  Hershey 
fonts  (e.g.  HERSHEY :SIMPLEX_ROMAN) 

CHARACTER  SET  LIST:  ASCII  plus  the  right  hand  part  of  Latin 
Alphabet  No.  1  (as  defined  in  ISO  8859-1) 

CHARACTER  CODING  ANNOUNCER:  basic  7  bit  and  basic  8  bit. 
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Therefore,  the  relationship  between  font  and  character  set  in  the 
CGM  is  an  implicit  one  inferred  through  the  use  of  ISO  character 
coding  standards. 


3 . 2  Character  Sets 

This  section  derives  a  phased  approach  to  character  set  usage  in 
CALS  CGM  files,  based  upon  the  requirements  and  existing 
commercial  practice. 


3.2.1  Character  Sets  in  Commercial  Practice 

Today  most  vendors  provide  a  proprietary  character  set  that 
includes  the  7-bit  ASCII  standard  of  ANSI  X3.4  as  a  subset.  Most 
8-bit  proprietary  character  sets  include  at  least  a  part  of  the 
right  hand  part  of  Latin  alphabet  No.  1.  Also,  most  proprietary 
character  sets  replace  less  frequently  used  ASCII  and  Latin 
characters  with  customized  glyphs.  Appendix  A  contains  example 
vendor-specific  character  sets  from  the  Apple  Macintosh  and  the 
IBM  PC  that  clearly  illustrate  this  phenomenon. 

In  addition,  a  variety  of  specialized  character  sets  are  used  in 
mathematics,  technical  illustrations,  and  engineering  drawings. 
These  special  character  sets  often  do  not  conform  to  the 
architecture  of  ISO  2022  and  have  never  been  registered  in  the 
International  Register  of  Coded  Character  Sets.  This  means  that 
,  no  standardized  escape  sequences  are  available  for  their 
invocation  in  a  CGM.  Appendix  B  illustrates  this  by  presenting 
extracts  from  IGES  4.0  that  show  the  14  "fonts”  that  are 
supported.  Many  of  these  "fonts"  have  custom  character  sets 
(glyph  collections)  defined  with  them. 

SGML  defines  the  following  set  of  "character  entity  sets"  all  of 
which  are  allowed  in  CALS  SGML  files  by  MIL-M-28001A: 

1)  Added  Latin  1 

2)  Added  Latin  2 

3 )  Greek  Letters 

4 )  Monotoniko  Greek 

5)  Russian  Cyrillic 

6)  Numeric  and  Special  Graphic 

7)  Diacritical  Marks 

8)  Publishing 

9)  Box  and  Line  Drawing 

10)  General  Technical 

11)  Greek  Symbols 

12)  Alternative  Greek  Symbols 

13)  Added  Math  Symbols;  Ordinary 


14)  Added  Math  Symbols:  Binary  Operators 

15)  Added  Math  Symbols:  Relations 

16)  Added  Math  Symbols:  Negated  Relations 

17)  Added  Math  Symbols:  Arrow  Relations 

18)  Added  Math  Symbols:  Delimiters 

The  SGML  standard  mentions  that  these  groupings  reflect  the 
requirements  of  ISO  6937,  but  these  particular  character  sets 
cannot  be  found  in  any  ISO  character  set  standard  or  in  the 
International  Register. 


3.2.2  A  Phased  Approach  to  Character  Sets  for  CALS  Use 

Many  CALS  requirements  can  be  met  by  using  the  two  character  sets 
supported  in  the  CALS  CGM  AP  today:  ASCII  and  the  right  hand  part 
of  Latin  alphabet  No.  1.  Unfortunately,  many  technical 
illustrations  derived  from  IGES  files  will  contain  special 
"characters”  from  the  Symbol  1,  Symbol  2,  and  Drafting  fonts. 
There  are  many  examples  of  technical  illustrations  that  contain 
Greek  letters  or  mathematical  symbols.  To  meet  these  long  term 
requirements  the  special  SGML-defined  character  sets  described 
above  should  be  supported,  as  well  as  the  IGES  character  sets 
described  above. 

There  are  three  feasible  approaches  to  meeting  these 

requirements: 

1)  Propose  the  needed  character  sets  for  registration 
through  ISO. 

2)  Add  the  needed  character  sets  to  the  CALS  CGM  AP  and 
designate  private  escape  sequences  to  designate  them. 

3)  Leave  it  up  to  each  DoD  program  to  define  any 
additional  character  sets  it  needs. 

The  second  approach  is  best  in  the  near  term:  add  at  least  three 
IGES  character  sets  (Symbol  1,  Symbol  2,  and  Drafting  fonts)  and 
the  eighteen  SGML  character  sets  to  the  CALS  CGM  AP.  The  process 
of  formal  ISO  registration  of  these  character  sets  could 
simultaneously  begin,  as  this  would  be  a  preferable  long-term 
approach.  (None  of  these  character  sets  appear  in  the  register 
today. ) 


3.3  Character  Set  and  Glyph  Association 

Longer  term,  CALS  requirements  are  best  met  by  defining  CGM 
extensions  that  de-couple  the  notion  of  character  set  from  glyph. 
As  the  full  DIS  9541  font  resource  model  is  implemented  in  the 
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CGM  such  a  glyph-to-character  set  association  will  no  longer  be 
available  as  it  is  today  due  to  the  exclusive  use  of  coding 
standards  developed  by  ISO/IEC  J.TC1/SC2.  With  this  report  a  new 
CGM  element  is  being  proposed  that  will  allow  the  association  of 
a  set  of  codes  with  a  set  of  structured  glyph  names  and  with  an 
escape  sequence.  It  is  likely  to  be  needed  in  the  long  run  by 
CALS.  Since  it  will  take  some  time  to  achieve  consensus  in  this 
area,  it  may  be  best  to  start  the  process  now. 

The  requirements  developed  for  this  CGM  extension  are  that  it; 

1)  be  independent  of  code  length  (allowing  8,  16,  32,... 

bit  coded  "character  sets") ; 

2)  allow  registration  of  commonly-used  associations  and 
their  invocation  by  a  simple  identifier; 

3)  be  compatible  with  DIS  9541  and  ISO  10036  (e.g.  use 

structured  glyph  names) ; 

4)  allow  specification  by  changing  only  selected  codes 
from  a  standard  set; 

5)  allow  citation  of  any  ISO  registered  glyph  collection 
in  a  straightforward  and  simple  manner. 

6)  allow  definition  of  a  glyph  collection  and  its 
association  with  a  "character  set"  in  a  straightforward 
and  simple  manner. 

The  specific  escape  proposed  does  not  meet  all  these  requirements 
since  additional  technical  work  is  needed  in  this  area.  It  will 
however  meet  near-term  requirements  in  an  expeditious  manner. 


3.4  Font  List  Contents 

This  section  addresses  requirements  for  "calling  out"  fonts  in 
the  CGM.  It  surveys  current  vendor  practice,  the  requirements 
imposed  by  DIS  9541  compatibility,  and  CALS  requirements.  Based 
on  these  it  develops  a  phased  approach  to  font  list  contents  in 
CALS. 


3.4.1  Fonts  in  Commercial  Practice 

Commercially  available  computers  and  peripherals  use  a  wide 
variety  of  different  fonts.  Appendix  B  lists  the  font 
capabilities  of  many  commercially-available  printers  and 
plotters.  It  is  readily  apparent  that  a  small  core  of  fonts,  or 
their  generic  equivalents,  are  widely  implemented.  These  are: 
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-  Helvetica 

-  Times 

-  Courier 

In  addition,  it  is  apparent  that  a  wide  variety  of  fonts  are 
available  to  meet  special  needs.  The  availability  of  many  of 
these  fonts  is  restricted  to  a  single  manufacturer. 

Inspection  of  many  IGES  files  indicates  that  most  engineering 
drawing  exchanges  use  either  Symbol  1  or  Symbol  2  fonts.  These 
fonts/character  sets  are  not  widely  supported  outside  of  CAD 
systems . 

Fonts  in  systems  today  are  generally  acquired  from  a  small  set  of 
vendors.  These  include  MonoType,  Allied,  Bitstream  Inc., 
International  Typeface  Corporation  (ITC) ,  URW  Corp.,  Adobe,  and 
Compugraphic  Corporation.  While  the  master  descriptions  of  a 
font  are  generally  in  "analog"  form  as  drawings  on  paper  (see  the 
examples  in  Appendix  B) ,  they  are  usually  translated  into  one  of 
a  variety  of  shape  representation  technologies,  such  as  raster 
bitmaps  and  Bezier  curves,  for  use  within  a  system. 

Many  vendors  provide  publically  available  font  metrics  in  file 
form.  These  files  are  not  substantially  different  from  the 
ecjuivalent  subsets  of  a  DIS  9541  font  resource.  Appendix  B 
contains  a  description  of  the  font  metric  file  format  used  by 
Adobe  Systems. 


3.4.2  A  Phased  Approach  to  Font  Lists  for  CALS  Use 

Most  CALS  requirements  for  fonts  in  technical  illustrations, 
which  is  the  most  immediate  CALS  need,  can  be  met  with  a  very 
small  set  of  government  mandated  fonts.  These  include: 

-  Helvetica,  or  a  look-alike 

-  Times,  or  a  look-alike 

-  Courier,  or  a  look-alike 

-  mathematical  symbol  fonts 

At  the  point  when  CALS  wants  engineering  drawings  transferred 
using  the  CGM,  then  at  least  the  two  IGES  "symbol”  fonts  will 
have  to  be  added. 

Last  fiscal  year  NIST/NCSL  submitted  the  first  of  a  series  of 
registration  proposals  for  adding  enhanced  text  font  capabilities 
to  the  CGM.  The  approach  taken  then  was  to  match  predominant 
commercial  practice  and  minimize  interpretation  burdens  on 
implementers  by: 

1)  using  font  family  names,  like  Helvetica  and  Times,  in 
the  font  list; 


2)  set  the  other  attributes  of  the  font  by  escape 
functions  (for  example,  boldness  is  turned  on  and  off 
by  an  escape) ; 

The  rationale  for  this  approach  was; 

1)  It  minimized  the  size  of  the  font  list  and  the  number 
of  names  that  must  be  either  registered  or  agreed  upon 
by  profile  or  private  agreement.  For  example,  if  font 
names  rather  than  font  family  names  are  used,  then 
registering  names  (or  assigning  them  in  a  profile) 
would  require  the  listing  of  at  least  6  postures  X  10 
weights  X  9  proportional  widths  X  5  structures  =  2700 
names  for  a  single  family  such  as  Helvetica!  (This 
assumes  listing  all  possible  variants  of  posture, 
weight,  proportional  width,  and  structure  identified  in 
DIS  9541.  For  example,  there  must  be  separate  listings 
for  Times  Italic  Bold  Medium  Solid  and  Times  Upright 
Bold  Medium  Solid.) 

2)  It  minimized  to  difficulty  of  parsing  the  names  in  a 
font  list  to  recover  attributes. 

3)  It  recognized  that  most  systems  have  an  entire  font 
family  in  all  sizes  and  many  attributes  available; 
those  systems  (notably  low  cost  laser  printers)  that  do 
not  have  an  entire  font  family  cannot  derive  their  font 
support  requirements  from  the  font  list  anyway,  since 
their  "font  resources”  are  size  dependent. 

The  next  logical  step  beyond  this  approach  is  to  allow  structured 
font  names  (registered  or  private)  in  the  font  list.  Such  names 
can  imply  some  attributes  of  a  typeface  ("font") ,  including  such 
things  as  its  weight  (boldness)  and  posture  (italicness) . 
Unfortunately,  it  will  be  several  years  before  the  mechanisms  of 
DIS  9541  are  in  place  and  a  set  of  conforming  font  resources  are 
available.  There  is  even  some  doubt  as  to  whether  the  major  font 
foundries,  such  as  ITC  and  Bitstream,  will  participate  in 
defining  font  resources  for  their  fonts.  (They  do  not 

participate  in  the  work  within  ISO/IEC  JTC1/SC24  that  is 
developing  the  necessary  standards.)  Therefore  full  DIS  9541 
support,  including  use  of  registered  names  and  vendor-supplied 
font  resources,  must  be  regarded  as  a  long  term  goal. 

The  arguments  above  then  lead  into  a  consideration  of  what  the 
next  logical  steps  should  be  towards  getting  useful  font 
information  in  CALS  CGM  files.  The  options  are: 

1)  Continue  to  allow  only  the  Hershey  fonts  as  options 
(the  current  MIL-D-28003  approach) ; 
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2) 


Invent  a  set  of  "generic”  font  descriptions  for  use 
with  CALS.  Add  these  to  MIL-D-28003;  or 

3)  Use  the  typographic  names  of  fonts  as  used  in  current 
commercial  practice  in  the  font  list,  where  the 
allowable  names  could  be: 

a)  registered; 

b)  listed  in  the  CALS  AP  (MIL-D-28003);  or 

c)  left  up  to  individual  DoD  programs  to  specify. 

In  considering  these  options,  it  is  concluded  that: 

1)  Option  1  is  rejected  because: 

a)  The  Hershey  fonts  do  not  represent  current 
practice  in  document  and  illustration  systems.  In 
fact  all  these  systems  have  used  typographic  fonts 
''or  some  time  and  none  support  Hershey  fonts.  (See 
the  data  sheets  in  Appendix  B.) 

b)  The  quality  achievable  with  Hershey  fonts  is  not 
acceptable  in  commercial  practice. 

2)  Option  2  is  rejected  because: 

While  generic  font  names  may  be  used  within  a 
single  document  and  illustration  system,  generic 
variants  are  sufficiently  different  so  that 
interchange  cannot  be  based  on  them.  For  example, 
the  character  sets  supported,  the  kerning  pairs 
(or  lack  of  them) ,  and  even  the  escapement  values 
are  different  among  generic  variants  of  the  same 
font.  ("Generic  variant"  in  this  sense  means,  for 
example,  the  creation  of  a  "Swiss"  font  by  a 
vendor  to  avoid  licensing  the  trademarked  name 
Helvetica. ) 

Therefore,  only  option  3  has  the  possibility  of  matching  current 
commercial  practice. 


3.5  Registration  of  "Font"  Names 

The  feasibility  of  registering  the  trademarked  names  of  actual 
fonts  for  interim  use  with  computer  graphics  standards  has  been 
explored.  However,  several  difficulties  with  this  approach  have 
emerged  that  cannot  be  overcome.  They  are: 

1)  The  one  example  of  text  font  registration  in  the 
registration  procedures  includes  glyph  shape 
information.  This  information  is  not  publicly 
available  for  "real"  fonts.  Therefore  only  the  names 
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and  the  glyph-to-code  correspondence  could  be  listed  in 
the  proposals.  Such  proposals  will  be  regarded  as 
incomplete  by  some  countries  such  as  the  UK,  and  are 
unlikely  to  be  accepted. 

2)  All  glyphs  in  a  given  character  set  may  not  be 
represented  in  a  font.  Some  countries  (notably  the  UK) 
have  indicated  they  will  not  approve  any  registration 
proposals  that  do  not  code  the  complete  character  set. 
This  problem  is  the  same  one  that  prevents  registration 
of  the  Hershey  fonts. 

3)  Within  ANSI  X3H3,  many  prominent  companies  have  stated 
that  they  will  oppose  the  registration  of  any  font 
names  at  all.  Their  feeling  is  that  only  IS  10036 
registered  glyph  collection  names  should  be  used. 

4)  Registering  a  complete  set  of  typographic  font  resource 
names  is  combinatorially  prohibitive,  as  there  is 
typically  one  such  resource  for  each  combination  of 
font  attributes.  The  2700  names  per  font  family 
derived  above  is  not  too  unrealistic.  For  example, 
Adobe  and  Bitstream  sell  over  240  types  Helvetica  fonts 
today,  each  with  a  different  set  of  attributes! 

Consequently,  it  would  be  counterproductive  to  attempt  to 
register  a  set  of  font  names  for  use  by  CALS.  Further,  it  is 
very  unlikely  due  to  very  dynamic  marketplace  conditions  (the 
Adobe  and  Apple/Microsoft/IBM  font  interchange  format  "wars”) 
that  any  major  font  vendors  will  seek  to  voluntarily  use  the 
mechanisms  of  IS  10036  any  time  soon.  Therefore  the  only 
feasible  approach  may  be  to  modify  the  CALS  CGM  AP  to  specify 
allowable  "font”  names,  which  would  require  that  the  changes 
(outlined  in  the  next  section  below)  to  the  CALS  CGM  AP  should  be 
considered  during  some  future  revision. 


3.6  Recommended  Approach  to  Font  Naming  in  CALS 

Based  on  the  above  rationale  and  trade  studies,  including  a  basic 
set  of  trademarked  names  in  the  CALS  AP  should  be  considered 
during  a  future  revision,  plus  freely  allowing  individual  DoD 
programs  to  specify  other  font  names  as  needed  to  meet  their 
needs.  The  reasons  for  this  are: 

1)  It  is  not  feasible  to  register  real  font  names. 

2)  Individual  programs  with  homogeneous  equipment  may  wish 
to  use  more  specialized  fonts.  This  should  not  be 
prohibited  unless  there  is  an  overwhelming  DoD-wide 
interest  in  insuring  that  all  illustrations  and 
drawings  are  imageable  on  all  systems  with  "equivalent" 
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results.  This  may  not  be  a  "requirement”  since  it  is 
not  only  technically  infeasible  today,  but  would 
greatly  increase  the  cost  and  reduce  their  quality 
significantly. 

3)  There  would  appear  to  be  no  legal  problems  with  listing 
trademarked  names  in  an  AP,  so  long  as: 

a)  the  trademark  is  cited; 

b)  the  fonts  are  widely  implemented  and  available 
from  multiple  sources;  (For  example,  Times  and 
Helvetica  are  both  registered  trademarks  of  Allied 
Corporation;  but  Times  and  Helvetica  versions  are 
sold  by  multiple  sources  and  available  in  many 
printers. ) 

c)  the  specification  of  alternate  fonts  by  name  is 
freely  allowed  in  the  profile; 

d)  generators  and  interpreters  are  free  to  use 
substitute  fonts  with  "equivalent"  metrics.  (This 
would  require  that  the  font  metrics  be  both 
released  by  the  vendors  and  transmitted  in  some 
fashion  with  the  CGM  file  so  that  a  match  could  be 
made . ) 

4)  Receiving  systems  with  generic  versions  of  trademarked 
font  names  can  easily  determine  an  appropriate 
substitution. 

Therefore,  the  following  approach  for  defining  names  in  the  CGM 
font  list  has  been  developed  and  should  be  considered  for 
addition  to  the  CALS  CGM  AP  as  a  future  revision: 

1)  allow  interpreters  and  generators  to  map  local  fonts 
into  "close  equivalent"  font  names  where  portability  is 
enhanced,  as  long  as  such  a  mechanism  does  not  restrict 
competition  and  the  font  metrics  are  available  to  all; 

2)  allow  compact  font  lists  that  list  only  partially 
descriptive  font  names,  combined  with  the  use  of  escape 
functions  that  state  attribute  selections  allow  optimal 
font  substitution  strategies; 

3)  explicitly  list  the  following  names  as  allowed  in  a 
font  list,  while  recognizing  that  neither  generators  or 
interpreters  need  use  fonts  from  the  trademark  owners: 

a)  Times 

b)  Helvetica 

c)  Courier 
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[It  is  not  feasible  to  list  either  SGML  or  IGES-derived 
font  names  at  this  time  since  accompanying  character 
sets  have  not  yet  been  defined.] 

4)  continue  to  allow  the  use  of  the  present  Hershey  fonts 
for  upward  compatibility; 

5)  define  an  explicit  way  of  constmicting  names  for  font 
lists. 

Based  on  the  various  trade  studies  in  this  report,  including  the 
one  on  font  substitution  below  the  following  naming  technique  has 
been  derived: 

1)  No  "naming  authority"  name  should  be  used. 

2)  Each  name  should  begin  with  a  font  family  name. 

3)  Additional  portions  of  the  names  can  specify  as 
detailed  of  font  attributes  as  wished  and  in  any  order; 
the  attributes  that  can  be  specified  are  restricted  to 
these  from  DIS  9541: 

a)  posture 

b)  weight 

c)  proportional  width 

d)  structure 

e)  scores. 

In  each  case,  the  attribute  name  must  be  one  of  those 
specified  in  DIS  9541,  except  in  the  case  of  scores, 
where  the  names  "underscore",  "overscore",  and 
"throughscore"  shall  be  used.  [Use  of  the  DIS  9541 
names  is  needlessly  complex  and  non-intuitive  since  a 
left-to-right  writing  mode  is  assumed. ] 

4)  Portions  of  names  should  be  separated  by  the  "standard" 
separator  symbol  used  in  OSI  and  office  systems  naming. 
This  is  the  solidus  glyph  (/) . 

5)  Only  characters  (and  codes)  in  ASCII  (X3. 4-1977)  should 
be  used  in  names. 

6)  Those  attributes  that  are  explicitly  listed  in  the  font 
list  shall  not  be  substituted  by  the  receiving  system. 

7)  Those  attributes  that  are  selected  by  the  registered 
Escape  functions  (posture,  weight,  proportionate 
weight,  structure,  and  scores)  can  be  substituted  with 
the  closest  available  equivalent  value.  The  closest 
available  equivalent  is  a  value  that  is  closest  to  the 
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selected  one  in  the  ordered  list  of  attributes  in  DIS 
9541.  For  example,  both  medium  and  ultra  bold  are 
allowable  substitutes  for  bold,  if  semi-bold  and  extra 
bold  are  not  available.  If  the  selected  value  is 
available,  it  shall  be  used.  [Both  generators  and 
interpreters  are  always  free  to  substitute  the  "font 
family  name"  by  an  equivalent.] 

Here  are  some  examples  of  how  this  would  work: 

1)  The  following  names  would  all  be  allowable  in  a  Font 
List: 

Helvetica 

New  Century  Schoolbook 

Times/bold/italic 

Times/ italic/bold 

Helvetica/ ital ic/normal/medium 

Courier/underscore 

2)  If  a  bold  Helvetica  font  is  required  then  the  Font  List 
should  contain:  "Helvetica/bold". 

If  substitution  is  allowable,  the  font  list  should  contain: 
"Helvetica"  and  the  Select  Typeface  Weight  (bold)  escape  function 
should  be  used  to  indicate  the  preference  for  bold. 

It  is  left  for  further  study  whether  there  is  a  meaningful  way  to 
include  typeface  design  grouping  in  a  font  naming  scheme.  In 
this  regard  it  can  be  pointed  out  that  terms  used  colloquially  in 
the  computer  graphics  community,  and  indeed  in  many  font  lists, 
are  not  used  correctly.  For  example.  Serif  and  Sans-serif  are 
not  major  typeface  design  groups,  but  are  in  fact  subgroups  that 
occur  in  many  design  groups.  For  example,  the  familiar  Times 
Roman  font  family  is  classified  as  a  "Rounded  Legibility"  font 
(It  was  designed  in  1931  for  the  Times  of  London  to  squeeze  more 
type  onto  a  page  in  a  "legible"  way!).  Most  graphics  experts 
would  call  it  a  "serif"  font!  The  familiar  Helvetica  font,  on 
the  other  hand,  is  a  "Sans  serif  Gothic  Neo-grotesque"  font. 


3 . 7  CGM  Text  Model  Extensions 

This  section  contrasts  the  CGM  text  model  with  the  information 
available  in  a  DIS  9541  font  resource  and  with  the  requirements 
of  commercial  typographic  practice. 


3.7.1  Basic  Text  Model 
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The  CGM  standard  recognizes  the  following  positioning  points  for 
text  alignment: 


1) 

top 

6) 

left 

2) 

cap 

7) 

right 

3) 

half 

8) 

centre 

4) 

base 

9) 

continuous 

vertical 

5) 

bottom 

10) 

continuous 

horizontal 

These  points  are  shown  in  Figure  1. 

Body 

-top 
-cap 

-haK 

■basa 

-txjttom 

left  center  right 

Figure  1.  CGM  "font  description  coordinate  system" 

The  CGM  standard  recognizes  four  text  paths: 

1)  right  3)  up 

2)  left  4)  down 

The  "font  model"  of  DIS  9541  uses  the  term  "alignment  line" 
rather  than  baseline,  since  the  later  only  has  meaning  in 
horizontal  writing  directions.  A  different  alignment  line  can  be 
specified  for  each  writing  mode.  This  is  illustrated  in  Figure 

2. 
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Figure  2.  DIS  9541  text  model. 
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The  four  supported  writing  modes  in  DIS  9541  (see  section  above) 
correspond  directly  to  CGM  text  paths.  Data  to  implement  CGM 
baseline  and  centre  alignment  can  be  derived  from  the  alignment 
lines  in  the  various  writing  modes.  In  addition,  the  top,  base, 
left  and  right  alignment  points  can  be  derived  from  the  Maximum 
Forward,  Left,  Backward,  and  Right  Extents  in  the  font  resource. 
(The  correspondence  is  writing-mode  dependent.) 

There  is  no  "capline"  information  in  a  font  resource,  but  the 
needed  information  can  be  derived  from  the  Left  Extent  of  the 
Capital  H  character  in  left  to  right  writing  mode.  (This  is  the 
actual  measurement  that  is  used  in  typographic  practice  for  Latin 
alphabets.)  There  is  no  "half line"  information  in  a  font 
resource,  but  the  needed  information  can  be  derived  from  the  left 
extent  of  the  lower  case  "x"  in  left  to  right  writing  mode. 
(This  is  the  actual  measurement  that  is  used  in  typographic 
practice  for  Latin  alphabets.)  Information  to  implement 
continuous  alignments  can  be  similarly  derived  from  the 
positioning  point  extent,  and  glyph  shape  information  in  a  font 
resource.  Table  1  below  summarizes  this  information: 


TABLE  1.  Deriving  CGM  Text  Attributes  from  a  Font  Resource 


9541  Font  Information 


CGM  Alignment 


left  to  right  mode,  alignment  line 
right  to  left  mode,  alignment  line 
top  to  bottom  mode,  alignment  line 
bottom  to  top  mode,  alignment  line 
writing  mode  dependent  extent  data 
writing  mode  dependent  extent  data 
writing  mode  dependent  extent  data 
writing  mode  dependent  extent  data 
left  to  right  mode,  left  extent  of  "H" 
left  to  right  mode,  left  extent  of  "x" 
positioning  point,  extents,  glyph  shape 
positioning  point,  extents,  glyph  shape 


baseline 

baseline 

centre 

centre 

top 

bottom 

right 

left 

cap 

half 

continuous  horizontal 
continuous  vertical 


No  revisions  are  necessary  to  the  basic  text  model  by 
registration  to  make  the  DIS  9541  information  usable  with  the 
CGM.  CGM  addenda  work  should  consider  a  closer  alignment  of  text 
and  font  terminology  at  the  next  revision  of  the  standard. 


Two  CGM  text  attributes  do  not  correspond  to  typographic  practice 
(for  revisable  documents)  are: 


1)  CHARACTER  EXPANSION  FACTOR 

2 )  CHARACTER  SPACING 
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The  use  of  these  attributes  should  be  deprecated  by  the  CALS  CGM 
AP  since  they  conflict  with  typographic  layout  practice  and 
hinder  font  substitution. 

Finally,  MIL-STD-1840A  and/or  the  CALS  Handbook  will  need  to  be 
modified  at  some  future  point  to  allow  the  inclusion  of  font 
resources  as  a  file  type,  or  at  least  insure  that  the  font 
metrics  are  made  available  so  that  a  "close  approximation"  to  the 
actual,  proprietary  fonts  may  be  realized. 


3.7.2  Graphical  Primitives  for  Text 

As  reported  previously,  the  CGM  text  model  and  primitives  are  not 
suitable  for  CALS  use  without  modification,  since  they  do  not 
support  modern  typographic  practice.  Once  CGM  Addendum  3 
functionality  has  been  adopted  this  problem  will  be  resolved. 

New  text  primitives  are  not  needed  in  the  CGM,  since  an  existing 
primitive  can  be  easily  modified  to  meet  requirements.  (Adding 
new  primitives  by  registration  as  GDPs  would  severely  impact  the 
portability  of  the  resulting  CGM  files,  since  any  interpreter 
that  did  not  understand  the  GDPs  would  get  no  text.  At  least  an 
interpreter  that  fails  to  understand  the  Set  Fully  Justified  Text 
escape  would  only  layout  and/or  size  text  incorrectly.) 

Additional  control  over  the  line  layout  algorithm  that  is  applied 
to  position  individual  text  characters  into  a  string  that  fits  a 
given  restriction  box  are  also  needed.  The  problem  is  that 
individual  systems  and  printers  apply  different,  proprietary 
algorithms  to  fit  text  into  a  given  space.  These  algorithms  may 
modify: 

1)  the  space  between  characters; 

2)  the  space  between  words; 

3)  the  shape  (and  consequently  the  extent)  of  individual 
characters . 

The  possibility  of  adding  an  additional  escape,  or  modifying  the 
one  already  proposed,  to  allow  specification  of  the  layout 
algorithm  has  been  investigated  .  It  has  been  concluded  that  it 
is  adequate  at  present  to  add  a  suggested  default  layout 
algorithm  to  the  description  of  the  Set  Fully  Justified  Text 
escape.  This  has  been  done. 


3.8  Font  Siibstitution  Support 

Font  substitution  is  a  subject  of  considerable  importance  in  open 
interchange  of  graphical  information.  Since  the  generating  and 
interpreting  systems  may  not  have  "equivalent"  fonts  installed  or 


available,  sufficient  information  should  be  provided  to  allow  an 
intelligent  selection  of  alternative  fonts. 

There  are  two  approaches  to  font  substitution  information: 

1)  The  receiving  system  derives  the  data  from  information 

in  the  font  list.  In  current  practice  this  is  done  by 
using  either  simple,  '‘generic”  names  (such  as 

"SERIF/BOLD) ,  or  vendor-specific  names  (such  as 

"Helvetica”)  ,  that  can  be  parsed  to  derive  font 
characteristics.  Once  DIS  9541  is  widely  implemented, 
equivalent  information  will  be  available  from  the 

Minimum  Font  Description  Subset.  (Widespread 

implementation  of  DIS  9541  is  still  many  years  away.) 

2 )  The  CGM  can  be  extended  to  carry  the  data  in  the 

Minimum  Font  Description  Subset.  This  could  be  done  by 
adding  one  or  more  escape  functions  to  the  CGM. 

The  first  approach  is  probably  the  best  one  because: 

1)  Information  in  a  font  resource  should  be  used  by  the 
CGM,  not  duplicated  within  the  CGM.  Duplication  of 
this  information  within  the  CGM  can  lead  to  needless 
incompatibilities . 

2)  Even  if  the  Minimum  Font  Description  Subset  is  not 

available  to  a  CGM  interpreter,  the  name  of  the  font 
resource  alone  is  expected  to  carry  enough  data  to 
allow  substitution  in  most  cases.  (An  example  name 
would  be  Helvetica/Bold/Italic. ) 

3)  The  Font  Resource  Name  has  already  been  selected  as  the 
name  that  is  carried  in  the  "font  list",  (in  the  long 
run)  so  the  name  will  be  readily  available  for  use  in 
deriving  substitute  fonts. 

4)  The  set  of  fonts  that  will  be  used  most  often  in 
"portable"  interchange  will  actually  be  quite  small  and 
will  likely  be  restricted  by  application  profiles.  The 
information  in  the  Minimum  Font  Description  Subset  is 
likely  to  be  widely  available  for  these  fonts.  In  a 
CALS  environment  this  subset  could  be  included  on 
MIL-STD-1840A  tape  deliverables. 

5)  In  cases  where  special  Font  Resources  are  required, 
they  can  be  interchanged  along  with  the  CGM  files  to 
make  at  least  the  information  in  the  Minimum  Font 
Description  Subset  available. 

6)  The  first  approach  is  consistent  with  the  short  term 
approach,  where  "font  names"  specified  in  the  CALS  CGM 
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AP  are  used  in  the  font  list.  These  names  are 
sufficiently  structured  that  font  substitution 
information  can  be  derived  from  them. 

Font  substitution  will,  in  all  likelihood,  play  only  a  minor  role 
in  initial  CALS  data  exchanges  (that  is,  the  delivery  of 
documents  between  parties  for  the  first  time) .  This  is  because 
of  the  many  difficulties  pointed  out  above  in  achieving 
high-quality  results  with  non- identical  fonts.  In  commercial 
practice  today  where  high-quality  results  are  needed,  exchanges 
are  based  on  the  use  of  fonts  with  identical  metrics,  often  from 
the  same  vendor.  Contracts  calling  for  CALS  deliverables  should 
place  sufficient  restrictions  on  the  fonts  and  character  sets 
used  to  make  font  substitution  a  minor  concern. 

Continued  usability  of  CALS  deliverables  requires  that  documents 
be  reproducible  as  easily  as  possible  on  a  variety  of  equipment. 
This  is  necessary  when  suppliers  change  or  when  manufacturers  go 
out  of  business.  Consequently,  there  is  a  continuing  requirement 
to  indicate  font  substitution  information  within  a  CGM  file.  The 
registration  proposals  proposed  to  date  go  a  long  way  towards 
meeting  these  requirements,  but  further  work  and  study  will  be 
necessary  in  this  area. 


3.9  User-defined  Fonts 

There  are  several  circumstances  where  user-defined  fonts  may  be 
advantageous ; 

1)  When  a  specialized  drawing  containing  mathematics  or 
drafting-derived  material  (where  special  symbols  are 
used  routinely)  is  transferred  to  a  system  without 
necessary  font  support. 

2)  In  high-quality  graphics  arts  where  customization  of 
fonts  is  used  to  achieve  special  effects. 

3)  In  transfers  to  CGM  interpreters  where  adequate  font 
support  does  not  exist. 

None  of  these  requirements  exist  for  routine  CALS  data  exchanges. 
In  those  rare  cases  where  a  special  symbol  is  needed  ( for 
example,  as  part  of  a  label  for  an  illustration) ,  that  symbol  can 
be  drawn  in  the  CGM  file  with  geometric  primitives.  Consequently 
user-defined  fonts  are  not  viewed  as  a  required  CGM  extension  for 
CALS  use.  As  previously  stated,  contracts  calling  for  CALS 
deliverables  should  place  sufficient  restrictions  on  the  fonts 
and  character  sets  used  to  make  user-defined  fonts  unnecessary. 
Further,  as  mentioned  above,  needed  character  sets,  glyphs,  and 
glyph  collections  should  be  defined  and  proposed  for 
registration. 
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Nonetheless,  for  completeness,  alternative  approaches  to 
implementing  user-defined  fonts  are  described  below.  There  are 
two  feasible  approaches: 

1)  Use  the  Font  Resource  facilities  of  DIS  9541.  The  data 
in  a  font  resource  should  be  easily  interpretable  by 
most  computer  graphics  systems,  since  it  will  consist 
of  simple  graphical  primitives. 

2)  Develop  C0(  extensions  for  defining  fonts.  This  could 

be  done  by  adding  a  set  of  escape  functions  to 

"collect”  the  primitives  that  define  a  glyph  into  a 
glyph  description  and  to  define  the  glyph  metrics. 

The  choice  between  these  alternatives  is  clear:  the  Font  Resource 
facilities  of  DIS  9541  should  be  used.  A  standardized  mechanism 
in  DIS  9541  for  defining  fonts  is  being  added  but  is  still 

several  years  away.  To  provide  a  duplicate  facility  within  the 
CGM  would  be  counterproductive  and  hinder  compatibility  and 
interoperatibilty  of  office  systems  and  computer  graphics 
standards.  Further,  there  are  complex  issues  to  be  resolved 
dealing  with  "hints"  necessary  to  allow  outline  fonts  to  be 

rendered  at  different  resolutions.  Hinting  technologies  are 
poorly  understood  in  the  computer  graphics  community  today. 

There  is  no  justification  for  repeating  information  that  is 

readily  available  within  a  font  resource  inside  a  CGM  file. 
Therefore,  whenever  a  user-defined  font  is  required,  a  Font 
Resource  should  be  developed  for  it.  This  resource  could  then  be 
named  in  the  font  list  and  transferred  with  the  CGM  file  for  use 
by  the  receiving  system. 


27 


4.  NAMED  ITEMS  AND  SYMBOL  LIBKARIES 

The  final  task  was  to  develop,  an  approach  to  handling  named 
objects  and  symbol  libraries  within  the  CGM  framework.  First, 
requirements  in  this  area  are  reviewed  and  clarified,  alternative 
approaches  defined,  and  a  design  approach  derived.  Then  a 
solution  is  presented  that  requires  additions  to  the  CALS  CGM  AP, 
MIL-STD-1840A,  and  the  use  of  CGM  Addendvim  1  features,  but  only 
one  new  registration  proposal. 


4.1  Requirements  for  Named  Items  and  Symbol  Libraries 

The  requirements  for  "macro  objects"  and  symbol  libraries  derive 
from  two  principal  sources: 

1)  the  desire  to  reduce  the  size  of  an  individual  CGM  file 
by  including  repeated  information  only  once; 

2)  the  desire  to  reduce  the  size  of  files  by  not 
retransmitting  information  in  local  libraries; 

3)  the  desire  to  achieve  uniformity  by  incorporating 
standardized  objects  such  as  symbols  and  logos  into 
files  by  reference. 

In  addition,  requirements  for  named  objects  derive  from  a  desire 
to  identify  "compound  objects"  whose  attributes  can  be  changed  as 
a  whole  rather  than  dealing  with  each  individual  primitive  in  the 
object. 

Analyzing  the  above  requirements  in  the  context  of  CALS  near  term 
requirements  (technical  illustrations  transferred  on 
MIL-STD-1840A  tapes)  it  is  clear  that  file  size  is  a  lesser 
concern  for  two  reasons: 

1)  file  transfers  will  be  on  tape  or  optical  disk,  so  file 
size  is  less  important  (although  the  local  staging 
storage  needed  in  going  to  and  from  tape  is  still  an 
issue) ; 

2)  technical  illustrations  (as  opposed  to  engineering 
drawings)  contain  few  opportunities  for  compaction  by 
extraction  of  repeated  information. 

Further,  most  CGM  generators  and  interpreters  cannot  take 
advantage  of  a  "macro"  facility.  Thus  a  phased  approach  to  named 
objects  and  symbol  libraries  in  CALS  should  focus  on  externally 
referenced  symbols  initially,  then  on  providing  compaction  within 
individual  files  by  an  internal  "macro"  or  "global  segment" 
facility. 
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One  issue  that  arises  immediately  is  how  external  symbols  can  be 
named,  referenced,  and  transferred  for  CALS  use.  Assuming 
initially  that  an  1840A  tape  containing  all  the  symbols  needed  to 
produce  a  document  is  desired,  there  are  several  problems; 

1)  MIL-STD  1840A  formats  did  not  envision  the  use  of 

external  references  within  graphics  files  and  does  not 
provide  a  mechanism  for  CGM  files  to  refer  to  other  CGM 
files  on  a  standard  tape  deliverable.  This  can  be 

fixed  by  modifying  the  allowable  contents  of  CGM 
"header  files"  to  include  the  names  of  relevant  CGM 

files. 

2)  Naming  of  external  files  should  be  consistent  with 

their  callouts  in  SGML  files. 

Finally,  the  requirements  for  eventual  registration  and/or 
standardization  suggest  that  naming  be  compatible  with  the 
"structured  name"  concepts  used  in  office  system  and  OSI 
standards.  In  particular,  this  means  that: 

1)  names  should  begin  with  a  designator  for  a  naming 

authority,  whether  public  or  private; 

2)  the  remainder  of  the  name  should  then  be  constructed  in 
a  hierarchical  fashion  to  produce  complete  names. 

For  example,  an  acceptable  structured  name  might  be:  "US  DoD 
CALS/Electronic  Symbols/PNP  Transistor".  Unfortunately, 

MIL-STD-1840A  only  uses  4  character  designators  (such  as  DOOl) 
without  any  indication  of  naming  authority.  Further,  "compound 
names"  are  constructed  by  simple  concatenation  with  no  separators 
for  parts  of  names.  (This  is  adequate  as  long  as  names  are  fixed 
lengthi)  For  example,  a  CGM  file  might  be  named  DOOICOOI. 

There  is  a  longer-term  requirement  for  the  development  of 
standardized  libraries  of  named  objects  and  for  the  registration 
of  these  names.  It  does  not  appear  possible  to  use  a  subset  of 
the  DIS  9541  font  resource  objects  and  ISO  10036  glyph  name 
registration  techniques  for  these  purposes.  This  is  due  to  the 
fact  that  the  graphical  objects  to  be  described  will  require  more 
complex  primitives  than  those  required  to  describe  glyph  shapes. 
(The  present  intention  is  that  glyph  shape  technologies  will 
allow  several  different  techniques,  each  of  which  is  restricted 
to  use  only  very  simple  classes  of  graphical  primitives  -  such  as 
lines,  conics,  or  Bezier  curves.)  Perhaps  a  different 

registration  authority  than  the  one  used  for  fonts  would  be 
necessary. 
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4 . 2  Alternative  Approaches 

4.2.1  Naming 

The  alternatives  are: 

1)  use  •’semi-structured"  strings  as  names; 

2)  use  structured  (registerable)  names  in  the  OSI  sense. 

Since  no  formal  mechanism  is  in  place  for  registering  symbol 
names  (or  the  "names"  of  any  other  graphical  objects)  ,  the  best 
approach  is  to  simply  use  "strings"  for  names  in  any  proposals 
and  further  restrict  their  contents  in  the  CALS  CGM  AP.  The  use 
of  structured  names  is  not  yet  standard  practice  within  the 
computer  graphics  community  and  attempts  to  impose  a  structure 
through  registration  rather  than  standardization  will  only  delay 
the  approval  of  proposals. 

Consequently,  names  should  be  described  as  simple  "strings"  in 
registration  proposals.  A  future  revision  to  the  CALS  AP  should 
further  restrict  the  names  of  external  symbols  as  described 
below,  under  the  assumptions  that: 

1)  all  external  symbols  must  be  "deliverable"  on  a 
standard  1840A  tape; 

2)  symbols  are  stored  as  global  segments  within  a  CGM 
file,  as  described  below) . 

Thus,  the  derived  naming  technique  should  be: 

1)  no  "naming  authority"  name  should  be  used; 

2)  each  name  should  begin  with  the  file  name  of  the  CGM 
file  that  contains  the  symbol; 

3)  the  local  symbol  name  of  the  symbol  within  that  file 
should  come  next  (this  means  an  character 
representation  of  the  integer  segment  name) ; 

4)  portions  of  names  should  be  separated  by  the  "standard" 
separator  symbol  used  in  OSI  and  office  systems  naming. 
This  is  the  solidus  glyph  (/) . 

5)  only  characters  (and  codes)  in  ASCII  (X3. 4-1977)  should 
be  used  in  names. 

For  example,  the  symbol  for  a  PNP  transistor  might  be  stored  in 
segment  10  in  file  D001C003.  It  would  be  named  "D001C003/10" . 
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4.2.2  Symbol  Definition 

The  following  set  of  requirements  for  a  single  symbol  definition 
facility  for  the  CGM  that  can  be  used  internally  or  externally 
has  been  developed: 

1)  Symbols  should  be  able  to  be  referred  to  by  name. 

2)  When  an  ''internal”  (global)  symbol  is  not  present  in  a 
CGM,  there  should  be  a  way  to  inform  an  interpreter 
that  it  is  an  "external”  symbol.  The  external  context 
to  be  searched  is  not  standardized,  but  could  be  set  by 
profile  or  other  standard.  For  example,  it  m.ght  be 
limited  to  the  same  MIL-STD-1840A  deliverable  tape. 

3)  A  symbol  should  be  able  to  be  the  entire  contents  of  a 
CGM  file,  and  the  entire  contents  of  a  picture  should 
be  an  allowable  symbol.  [NOTE:  The  next  revision  of 
the  CALS  CGM  AP  will  not  deal  with  this,  but  it  will  be 
an  interesting  capability  and  a  requirement  once  the 
CALS  CGM  AP  is  allowed  for  use  in  transferring 
engineering  drawings.] 

4)  The  metafile  and  picture  attribute  associated  with  a 
symbol  need  not  be  the  same  as  those  of  the  metafile 
that  references  it.  In  particular,  attributes  such  as 
colour  precision,  VDC  type  and  precision,  VDC  extent, 
colour  specification  mode,  colour  table,  and  integer 
precision  may  all  be  different.  This  is  essential  if 
the  symbol  library  generation  process  is  to  be 
decoupled  from  the  metafile  interpretation  process. 

5)  Symbols  should  be  insertable  by  specifying  (in  effect) 
position,  scaling,  and  rotation. 

6)  An  arbitrary  position  point  (in  local  VDC)  should  be 
associated  with  each  symbol. 

7)  All  attributes  not  specifically  specified  within  a 
symbol  definition  should  be  inherited  from  the  defining 
context . 

8)  No  attribute  settings  within  a  symbol  should  change 
continuing  interpretation  of  the  including  file. 

9)  Symbol  names  should  be  of  unrestricted  length  to  allow 
the  convenient  construction  of  structured  names  and 
external  references. 

After  reviewing  the  features  of  CGM  Addendum  1  in  light  of  these 
requirements  (with  the  view  of  using  CGM  segments  as  symbols)  it 
appears  that: 
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1)  The  “inheritance  filter"  concepts  in  Addendum  1 
adequately  addresses  attribute  inheritance  at  both  the 
level  of  the  CGM  and  of  APIs.  It  is  much  more  complex 
than  required  for  CALS  purposes  and,  if  fully  required, 
will  place  an  extreme  burden  on  implementers  of  CALS 
CGM  interpreters. 

2)  The  restrictions  that  segment  names  to  be  "realized"  as 

integers  is  most  unfortunate,  but  actually  the  problem 
is  more  syntax  than  fundamental  semantics.  The 

Addendum  1  mechanism  gives  a  very  compact  and  efficient 
internal  name  for  a  segment.  The  difficulty  can  be 
overcome  by  adding  a  Segment  List  element  similar  in 
scope  and  purpose  to  a  Font  List. 

Nonetheless,  the  Addendum  1  features  are  usable  for  CALS 
purposes.  Consequently,  the  symbol  library  elements  developed 
under  this  task  will  not  be  proposed  for  registration,  since 
compatibility  with  (nearly)  standardized  elements  is  more 
important  than  the  ease  of  use  of  these  elements. 

Therefore,  symbols  that  can  be  externally  referenced  should  be 
stored  as  global  segments  in  some  CGM  file.  This  could  be  called 
out  in  a  local  file  by  name  using  the  Segment  List  element  being 
proposed  for  registration.  In  addition,  internal  symbols  could 
be  contained  in  segments  within  any  picture  body,  but  they  could 
not  be  externally  referenced. 
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5.  SPONSORSHIP  OF  REGISTRATION  PROPOSALS 

There  continue  to  be  long  delays  in  getting  registration 
proposals  approved  through  the  ANSI/ISO  process.  Most  of  these 
delays  are  due  to  demands  by  X3H3  members  that  registered  items 
have  the  same  level  of  "generality”  as  standardized  items.  This 
means  that  attempts  to  register  limited  and  CALS  specific  items 
have  not  been  successful,  and  that  more  work  has  been  required, 
and  will  continue  to  be  required  to  modify  proposals  than 
originally  anticipated. 

Despite  these  difficulties  the  use  of  registration  to  make 

computer  graphics  standards  suitable  for  CALS  use  has  been 
successful.  Virtually  without  exception,  NIST/NCSL  proposals 
have  been  adopted  by  X3H3  without  any  significant  technical 
change.  Comments  received  on  ballots  are  largely  editorial  in 
nature.  A  few  comments  ask  for  an  additional  level  of 

specification  of  error  handling  and  default  behavior  than  is  in 
common  commercial  practice.  Such  requests  are  easily 

accommodated . 

The  table  below  contains  the  current  status  of  those  registration 
proposals  worked  on  this  fiscal  year.  These  proposals  are 
divided  into  four  classes,  and  appear  in  their  entirety  in 
Appendix  C: 

1)  Proposals  approved  by  X3H3  in  September  1989  in  Letter 
Ballot  #80.  Final  text  ready  to  forward  to  ISO  is 
included  for  these. 

2)  Revised  proposals  from  Letter  Ballot  #76.  This  text  is 
ready  for  review  and  then  re-ballotting.  A  significant 
amount  of  technical  work  has  been  done  to  align  the 
proposals  with  DIS  9541  and  to  coordinate  them  with  the 
CALS  AP  revisions  being  developed  by  another 
contractor. 

3)  Partially  revised  proposals,  to  which  a  common  set  of 
editorial  corrections  have  been  applied,  but  which  need 
additional  technical  work  prior  to  ballot. 

4)  New  proposals  submitted  for  the  first  time  this  year. 
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Table  2.  Stialius  of  Registrabion  Proposals 


Class  of  Ibem  N2uiie  Stiabtis 


(Final  revised  text  for  these  proposals  is  provided  with  this  report.) 


Linetype 

User-specified  dash  pattern 

Approved  by  X3H3 ; 
with  this  report 

final 

text 

Escape 

Set  dash 

Approved  by  X3H3 ; 
with  this  report 

final 

text 

Escape 

Set  line  miter  limit 

Approved  by  X3H3 ; 
with  this  report 

final 

text 

Escape 

Set  line  cap 

Approved  by  X3H3 ; 
with  this  report 

final 

text 

Escape 

Set  line  join 

Approved  by  X3H3 ; 
with  this  report 

final 

text 

Escape 

Set  conic  arc 
transformation  matrix 

Approved  by  X3H3 ; 
with  this  report 

final 

text 

GDP 

Conic  arc 

Approved  by  X3H3 ; 
with  this  report 

final 

text 

GDP 

Parametric  spline  curve 

Approved  by  X3H3 ; 
with  this  report 

final 

text 

GDP 

Rational  B-spline  curve 

Approved  by  X3H3 ; 
with  this  report 

final 

text 

GDP 

Cubic  Bezier  curve 

Approved  by  X3H3 ; 
with  this  report 

final 

text 

(The  following  proposals  have  been  revised  based  upon  ballot  comments  are 

are  ready  for  a  second  round  of  ballot  comments.) 

Escape  Set  edge  miter  limit  minor  revisions  included  with 

this  report;  ready  for  review 
and  ballot 

Escape  Set  edge  cap  minor  revisions  included  with 

this  report;  ready  for  review 
and  ballot 

Escape  Set  edge  join  minor  revisions  included  with 

this  report;  ready  for  review 
and  ballot 
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T2J3le  2.  Statiis  of  Registiratlon  Proposals-con1:inued 


Class  of  Item 

N2uiie 

Status 

Escape 

Select  Typeface  Posture 

revised  and  renamed  proposal 
#46;  ready  for  review  and 
ballot 

Escape 

Select  Typeface  Structure 

revised  and  renamed  proposal 
#49;  ready  for  review  and 
ballot 

Escape 

Select  Typeface  Scores 

revised  and  rencuned  proposal 
#51;  ready  for  review  and 
ballot 

Escape 

Select  Typeface  Weight 

revised  and  renamed  proposal 
#52;  ready  for  review  and 
ballot 

Escape 

Set  Fully  Justified  Text 

revised  and  renamed  proposal 
#53;  ready  for  review  and 
ballot 

Escape 

Select  Typeface 

Proportionate  Width 

revised  and  renamed  proposals 
#54  and  #55  combined;  ready 
for  review  and  ballot 

(The  following  proposals  have  been  partially  revised  to  respond  to  comments 
of  an  editorial  nature,  but  additional  technical  work  will  be  necessary 
before  they  can  be  re-balloted.) 

GDP 

Pel  array 

revised  text  with  this  report; 
additional  technical  work 
needed  before  another  round  of 
balloting  within  X3H3 

Escape 

Set  direct  colour  response 

revised  text  with  this  report; 
additional  technical  work 
needed  before  another  round  of 
balloting  within  X3H3 

Escape 

Set  indexed  colour  response 

revised  text  with  this  report; 

additional  technical  work 
needed  before  another  round  of 
balloting  within  X3H3 
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Table  2. 
Class  of  Item 
(The  following 
Escape 

Escape 

Escape 


Status  of  Registration.  Proposals-continued 
Name  Status 

proposals  are  new  with  this  report. ) 

Select  General  Fill  ready  for  review  and  X3H3 

ballot 

Glyph  Association  ready  for  review  and  X3H3 

ballot 

Segment  List  ready  for  review  and  X3H3 

ballot 
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APPENDIX  A 

CHARACTER  SET  EXAMPLES 
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ASCII  CHARACTER  SET 
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TYPE 


GiiAilllC  GBAiiACreat  SET 

J&U  BE  CAilACTEBES 
GIUFHIQOliS 


REGlSTILVnOIt’  i.'br;BEE 
KBKliSK)  D'CIREGISTRIiSXHT 


006 


Gq  aet  /  jeu  Gq 

ESC  2/a  4/2 

Gf  aet  /  Jeu  G^ 

ESC  2/9  4/2 

MUmBYTE  SET 

JEU  KULTIPLBr 

nSCISTRATIOH  DATE 
DATE  D'ESIREGlSTRQIEliT 


1975/12/01 


ESCAPE  SEQUBICE 


SEQUQfCB 

B'ECHAPP31EHT 


NAl-lS/ilOll 

ASCII  Giaphic  chancter  aet 
Jeu  de  caiactArea  graphlquaa  ASCII 


iirscnimoH 

A  set  of  94  graphic  characters  which,  whan  invoiced  in  columns  2-7  of  a  7  bit  code  table 
or  an  3-bit  code  table  would  be  positioned  aa  shown  on  page  24.  Vihile  alternate 
meanings  are  stated  no  substitution  of  graphic  ia  Intentad. 

Jeu  de  94  caract^res  graphiquea  qui,  lorsqu*ils  sont  appelds  dans  les  colonnes  2  a  7 
d'un  tableau  de  code  h  7  ou  8  elements  doivent  Atre  positlonnds  conne  indique  en 
page  24.  Bien  qua  des  significations  de  reaplacement  soient  admises,  des  substitutions 
de  cnracteres  gxaphiquea  ne  sont  pas  prevues. 

oFOi;SOR/oaG,\i,’ISl-:E  ds  parrainage 


American  Hational  Standards  Institute  1450  Broadway  NEV  YOBK,  N.Y.  100  18  U.S.A. 
Organisms  National  de  Normalisation  des  Btats-lhiis 


:)RiGiN  (iisi:a)/oRiGi]?s  (uniJSATZua) 

American  National  Standard  X5.4  -  1968 
Nome  intemationale  amdricaine  X5.4  -  1968 


'lELB  0-'  ir'iiizATiCM'/DCMM:::-:  D’AFPLicvnc:: 


Coded  infonm  tion  interchange 
exchange  d*  informs  cion  codde 
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ASCII  graphic  sat 

Coded  zapraaeotation  when  Inwokad  la  eolma  2-7  of  coda  table 


ASCII  graphic  set 


LECEIfDS 

POSITION  WDEar 
INVOKED  IN 
COLUHNS  2-7 

GRAPBIC 

* 

NAME  OR  HEAHIHC 

(additional  names  in  PARENTHESIS  ARE  ALTERI/ATE  MiXMINCC 
DETERMINED  BT  SYNTAX  OR  USAGE  AND  ARE  NOT  SUSSTITDTION 
ALTERNATIVES^ 

2l\ 

I 

Exclamation  nark 

2/2 

■ 

Quotation  max^(dlaera8is) 

2/3 

Number  aign 

2/4 

$ 

Dollar  sign 

2/5 

Per  cent 

2/6 

ft 

Ampersand 

2/7 

/ 

Apostrophe  (closing  single  quotation  mark  , 
acute  accent) 

2/8 

( 

Left  parenthesis 

.  2/9 

) 

Right  parenthesis 

2/10 

• 

Asterisk 

2/1 1 

+ 

Plus 

2/12 

Comma  (cedilla) 

2/13 

- 

Hyphen  (mimis) 

2/14 

• 

Full  stop  (period,  decimal  point) 

2/15 

/ 

Solidus  (slant) 

3/0 

0 

Digit  sero 

3/1 

1 

Digit  ow 

3/2 

2 

Digit  t^o 

3/3 

3 

Digit  three 

3/4 

4 

Digit  four 

3/5 

5 

Digit  five 

3/6 

6 

Digit  six 

3/7 

7 

Digit  seven 

3/0 

8 

Digit  eight 

3/9 

9 

Digit  nine 
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ASCII  graphic  aet 
I£CEND6 


Colon 
Semi-colon 
Less  than  sign 
Equal  sign 
Greater  than  aign 
Question  mark 
Commercial  at 
Capital  letter  A 
Capital  letter  B 
Capital  letter  j; 
Capital  letter  D 
Capital  letter  E 
Capital  letter  F 
Capital  letter  G 
Capital  letter  H 
Capital  letter  I 
Capital  letter  J 
Capital  letter  K 
Capital  letter  L 
Capital  letter  H 
Capital  letter  H 
Capital  letter  0 
Capital  letter  P 
Capital  letter  Q 
Capital  letter  R 


ASCII  graphic  aat 


FOSITIOH  WBESf 
INVOKED  IN 
OOLOHNS  2-7 


GRAPHIC 


5/3 

5/4 

5/5 

5/6 

5/7 

5/8 

5/9 

5/iO 


S 

T 

H 

T 

W 

X 

T 

Z 


5/11 

5/12 

5/13 

5/14 

5/15 

6/0 

6/1 

6/2 

6/3 

6/4 

6/5 

6/6 

6/7 

6/8 

6/9 

6/lO 


[ 

\ 

] 


a 

b 

e 

d 

a 

f 

6 

b 

i 


6/ll 

6/12 


k 

1 


liSENDS 


NAME  OR  MEANING 


Capital  latter  S 

Capital  letter  T 

Capital  letter  U 

Capital  letter  V 

Capital  letter  V 

Capital  letter  X 

Capital  letter  T 

Capital  letter  Z 

Left  square  bracket 

Reverse  aolidua  (Reverse  slant) 

Ri^t  square  bracket 

Upirani  arrow  head  circumflex  accent 

Onderline 

Crave  accent  (opening  single  quotation  mark) 

Small  letter  a 

Small  letter  b 

Shall  letter  c 

Small  letter  d 

Shall  letter  e 

Shall  letter  f 

Small  letter  g 

Shall  letter  b 

&all  letter  1 

Shall  letter  J 

Shall  letter  k 

Shall  letter  1 
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ASCII  ^phic  Mt 


USENDS 

POSITION  VHE3I 

INVOKED  m 
COLUMNS  2-7 

GRAPHIC 

NAME  OR  MEANING 

6/13 

■ 

Staall  letter  m 

6/14 

tt 

letter  n 

6/15 

0 

Small  letter  o 

7/0 

P 

Staall  letter  p 

7/1 

<1 

small  letter  q 

7/2 

r 

Stall  letter  r 

ih 

B 

Shall  letter  s 

7/4 

t 

Shall  letter  t 

7/5 

n 

Shall  letter  u 

7/6 

T 

Small  letter  ▼ 

7/7 

w 

Shall  letter  m 

7/8 

z 

Shall  letter  z 

ih 

7 

Soall  letter  y 

7/10 

r 

Shall  letter  z 

7/11 

1 

Left  curly  bracket  (left  brace) 

7/12 

1 

Vertical  line 

7/13 

} 

Right  ctirly  bracket  (right  brace) 

7/14 

Tilde  (overllne,  general  accent) 
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(RIGHT  HAND)  LATIN  I 
CHARACTER  SET 
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TYPE: 


96-Character  Graphic 
Character  Set 


REGISTRATION  NUMBER:  100 
DATE  OF  REGISTRATION:  Feb.1.1986 


ESCAPE  SEQUENCE: 


GO: 

Gl: 

ESC.  2/lJ 

4/1 

G2: 

ESC  2/14 

4/1 

G3: 

ESC  2/15 

4/1 

CO: 

- 

• 

Cl: 

- 

NAME 

Right-Hand  Part  of  Latin  Alphabet  Nr.l 


DESCRIPTION 

A  96-character  set  intended  for  allocation  to  columns  10  to 
IS  of  the  8-bit  code  called  Latin  Alphabet  Nr.l  in  Internatio¬ 
nal  Standard  ISO  8859/1. 


SPONSOR  -  iS0/TC97/SC2/WG-7 

-  BCMA,  EUROPEAN  COMPUTER  MANUFACTURERS  ASSOCIATION 


ORIGIN  -  ISO  88S9/1 

-  Standard  ECMA-94 


FIELD  OF  UTILISATION 

This  set  of  graphic  characters  is  intended  for  use  in  data 
processing  and  text  applications  and  may  also  be  used  for  in¬ 
formation  interchange. 

The  set  contains  graphic  characters  used  for  general  purpose 
applications  in  typical  office  environments  in  the  following 
languages  : 

Danish,  Dutch.  English.  Faeroese.  Finnish.  French.  German. 
Icelandic.  Irish,  Italian.  Norwegian,  Portuguese,  Spanish  and 
Swedish. 
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|0{3[3I3[| 

[II  III  hi  All 


0 


oh  1 


ME 
Qi 
SflSQD 
BDEll 
SDQEil 


lop  5 


6 


0|l11 


10  0  1  9 


1  0  1  0  10 


10  11  11 


110  0  12 


110  1  13 


111014 


111  1  1 5 


0 

0 

1 

•1 

0 

1 

2- 

3 

1 

1 

0 

1 

1 

0 

5 

6 

■■■■■■■ 

f)  a  6 


*'*  /  2* 
Nan 


^  ^ 
A  0  a 


A  0  a 


0 


¥  n  a  olaio 


IT  /t 


$1  6 


9 


£  0  6  0 


'  E  U  e  Cl 


-  E  U  e  0 


«|»  E  0 


V.  i  u 


SHY  Vz  f  Y 


i  B  i-  y 
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Pos. 

Name 

4/0 

CAPITAL  LETTER  A  WITH  GRAVE  ACCENT 

4/1 

CAPITAL  LETTER  A  WITH  ACUTE  ACCENT 

4/2 

CAPITAL  LETTER  A  WITH  CIRCUMFLEX  ACCENT 

4/3 

CAPITAL  LETTER  A  WITH  TILDE 

4/4 

CAPITAL  LETTER  A  WITH  DIAERESIS 

4/5 

CAPITAL  LETTER  A  WITH  RING  ABOVE 

4/6 

CAPITAL  DIPHTHONG  A  WITH  E 

4/7 

CAPITAL  LETTER  C  WITH  CEDILLA 

4/8 

CAPITAL  LETTER  E  WITH  GRAVE  ACCENT 

4/9 

CAPITAL  LETTER  E  WITH  ACUTE  ACCENT 

4/10 

■ 

'  CAPITAL  LETTER  E  WITH  CIRCUMFLEX  ACCENT 

4/11 

CAPITAL  LETTER  E  WITH  DIAERESIS 

4/12 

CAPITAL  LETTER  I  WITH  GRAVE  ACCENT 

4/13 

CAPITAL  LETTER  I  WITH  ACUTE  ACCENT 

4/14 

CAPITAL  LETTER  I  WITH  CIRCUMFLEX  ACCENT 

4/15 

CAPITAL  LETTER  I  WITH  DIAERESIS 

5/0 

CAPITAL  LETTER  D  WITH  STROKE 

5/1 

CAPITAL  LETTER  N  WITH  TILDE 

5/2 

CAPITAL  LETTER  0  WITH  GRAVE  ACCENT 

5/3 

CAPITAL  LETTER  0  WITH  ACUTE  ACCENT 

5/4 

CAPITAL  LETTER  0  WITH  CIRCUMFLEX  ACCENT 

5/5 

CAPITAL  LETTER  0  WITH  TILDE 

5/6 

CAPITAL  LETTER  0  WITH  DIAERESIS 

5/7 

MULTIPLICATION  SIGN 

5/8 

CAPITAL  LETTER  0  WITH  OBLIQUE  STROKE 

5/9 

CAPITAL  LETTER  U  WITH  GRAVE  ACCENT 

5/10 

✓ 

CAPITAL  LETTER  U  WITH  ACUTE  ACCENT 

5/11 

CAPITAL  LETTER  U  WITH  CIRCUMFLEX  ACCENT 

5/12 

CAPITAL  LETTER  U  WITH  DIAERESIS 

5/nl 


rADTTAt  r  CTTHO  V  ft/rTU 


51 


Name 


Note 


Pos. 


2/0 


2/1 


2/2 


2/3 


2/5 


2/6 


in 


2IS 


2/9 


2/10 


2/11 


2/12 


2/13 


2/14 


2/15 


3/0 


3/1 


3/2 


3/3 


3/4 


3/5 


3/6 


3/7 


3/8 


3/9 


3/10 


3/11 


3/12 


3/13 


3/14 


3/15 


NO  BREAK  SPACE 


INVERTED  EXCLAMATION  MARK 


CENT  SIGN 


POUND  SIGN 


CURRENCY  SIGN 


YEN  SIGN 


BROKEN  BAR 


PARAGRAPH  SIGN 


DIAERESIS 


COPYRIGHT  SIGN 


•  FEMININE  ORDINAL  INDICATOR 


LEFT  ANGLE  QUOTATION  MARK 


NOT  SIGN 


SOFT  HYPHEN 


REGISTERED  TRADE  MARK  SIGN 


MACRON 


DEGREE  SIGN.  RING  ABOVE 


PLUS -MINUS  SIGN 


SUPERSCRIPT  TWO  . 


SUPERSCRIPT  THREE 


ACUTE  ACCENT 


SMALL  GREEK  LETTER  MU,  MICRO  SIGN 


PILCROW  SIGN 


MIDDLE  DOT 


CEDILLA 


SUPERSCRIPT  ONE 


MASCULINE  ORDINAL  INDICATOR 


RIGHT  ANGLE  QUOTATION  MARK 


VULGAR  FRACTION  ONE  QUARTER 


VULGAR  FRACTION  ONE  HALF 


VULGAR  FRACTION  THREE  QUARTERS 


INVERTED  QUESTION  MARK 


Fos. 

Name 

6/0 

SMALL  LETTER  a  WITH  GRAVE  ACCENT 

6/1 

SMALL  LETTER  a  WITH  ACUTE  ACCENT 

6/2 

SMALL  LETTER  a  WITH  CIRCUMFLEX  ACCENT 

6/3 

SMALL  LETTER  a  WITH  TILDE 

6/4 

SMALL  LETTER  a  WITH  DIAERESIS 

6/5 

SMALL  LETTER  a  WITH  RING  ABOVE 

6/6 

SMALL  DIPHTHONG  a  WITH  e 

6/7 

SMALL  LETTER  c  WITH  CEDILLA 

6/8 

SMALL  LETTER  a  WITH  GRAVE  ACCENT 

6/9 

SMALL  LETTER  e  WITH  ACUTE  ACCENT 

6/10 

SMALL  LETTER  a  WITH  CIRCUMFLEX  ACCENT 

6/11 

SMALL  LETTER  a  WITH  DIAERESIS 

6/12 

SMALL  LETTER  i  WITH  GRAVE  ACCENT 

6/13 

SMALL  LETTER  i  WITH  ACUTE  ACCENT 

6/14 

SMALL  LETTER  i  WITH  CIRCUMFLEX  ACCENT 

6/15 

SMALL  LETTER  i  WITH  DIAERESIS 

7/0 

SMALL  ICELANDIC  LETTER  ETH 

7/1 

SMALL  LETTER  n  WITH  TILDE 

7/2 

SMALL  LETTER  o  WITH  GRAVE  ACCENT 

7/3 

SMALL  LETTER  o  WITH  ACUTE  ACCENT 

7/4 

SMALL  LETTER  o  WITH  CIRCUMFLEX  ACCENT 

7/5 

SMALL  LETTER  o  WITH  TILDE 

7/6 

SMALL  LETTER  o  WITH  DIAERESIS 

7/7 

DIVISION  SIGN 

7/8 

SMALL  LETTER  o  WITH  OBLIQUE  STROKE 

7/9 

SMALL  LETTER  u  WITH  GRAVE  ACCENT 

7/10 

SMALL  LETTER  u  WITH  ACUTE  ACCENT 

7/11 

SMALL  LETTER  u  WITH  CIRCUMFLEX  ACCENT 

7/12 

SMALL  LETTER  u  WITH  DIAERESIS 

7/13 

SMALL  LETTER  y  WITH  ACUTE  ACCENT 

7/14 

SMALL  ICEUNDIC  LETTER  THORN 

7/15 

SMALL  LETTER  /WITH  DIAERESIS 

Note 
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NOTES 


The  definition  of  this  character  is  given  in  the 

standards  indicated  in  the  ORIGIN  field  of  this 
registration. 
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DEFAULT  C6M  CHARACTER  SET 


55 


ISO  8859-1: 1987  ( 


7.1  Characttn  ol  th«  Mt  and  thair  codad  raprasantailon 

TaWa  1  -  Charaetar  tat  —  Codad  rapraaantaUon 


■H 

eamat- 

nadofi 

■ 

Oil 

eemMi 

nadan 

Nama 

(8/00 

SMCE  (tta  0.31 

00/00 

GRAVE  ACCENT 

(Brai 

exclamation  MANX 

00/01 

SMAU  LETTER  a 

wm 

QUOTATION  M/MK 

00/02 

SMAULETTERb 

mm 

NUMOER  SIGN 

00/03 

SMAU  LETTER  c 

(8/0* 

DOLLAR  SIGN 

00/04 

SMAU  LETTER  d 

mm 

PERCENT  SIGN 

08/00 

SMAU  LETTER  a 

mim 

AMPERSAND 

CO/QB 

SMAULETTB1 1 

(8/07 

apostrophe 

00/07 

SMAULETTBIg 

(8/(8 

LEFT  PARBITHESIS 

OO/QB 

SMAULETTERb 

02/00 

RIGHT  MRB4THESIS 

08/IB 

SMAULETTERI 

02/10 

ASTERISK 

00/10 

SMAULETTERI 

02/11 

PLUS  SIGN 

00/11 

SMAULETTBIk 

02/12 

COMMA 

00/12 

SMAULETTERI 

02/13 

HYPHOI.  MINUS  SIGN 

08/13 

SMAULETTBIm 

02/14 

PUUSTOP 

08/14 

SMAULETTERb 

02/1S 

SOUOUS 

08/10 

SMAULETTBIe 

09/00 

OIGn’ZERO 

07/00 

SMAULETTERp 

03/01 

OIGff  ONE 

07/01 

SMAU  LETTER  q 

00/02 

OKRTTWO 

07/02 

SMAULEimr 

03/03 

OKRTTMRn 

07/03 

SMAULETTERI 

03/04 

OKRTPOUR 

07/04 

SMAULETTERI 

03/00 

OKRTRVE 

07/00 

SMAULETTERu 

03/06 

OMRTSa 

07/00 

SMAULETTBI* 

03/07 

ONRT  SEVEN 

07/07 

SMAULETTERw 

03/00 

OKRTOGHT 

07/08 

SMAULETTOi 

(EMO 

OKRTNME 

07/08 

SMAULETTHy 

00/10 

COLON 

07/10 

SMAULETmt 

03/11 

SEMICOLON 

07/11 

left  CURLY  BRACKET 

03/12 

UESS-THAN  SIGN 

07/12 

VOTICALIJNE 

03/13 

EQUALS  SIGN 

07/13 

mCHT  CURLY  BRACKET 

03/14 

greater-than  sign 

07/14 

THOE 

01/10 

QUESTION  MARK 

10/00 

WT-BREAK  SPACE  Oaa  B.3I 

04/00 

commeroal  at 

KVOI 

INVOITEO  EXOAAMTION  MARK 

04/01 

CAPHAL  LETTER  A 

lorai 

CBITSHN 

04/03 

CAPnAL  Lcrm  o 

10/03 

POUND  SIGN 

04/03 

capital  LETTER  C 

lonM 

CURRENCY  SIGN 

04/04 

capital  LETTER  0 

10/00 

VQISiaN 

04/00 

CAPITAL  LETTER  E 

lono 

BROKBIBAR 

04/00 

CAPITAL  LETTER  P 

10/07 

PARAGRAPH  SIGN.  SECTION  SIGN 

04/07 

CAPITAL  LETTER  G 

ions 

DIAERESIS 

04/00 

CAPITAL  LETTER  M 

lona 

COPYRIGHT  SIGN 

04/00 

CAPITAL  LETTER  1 

10/10 

TEMdaiNE  ORDINAL  INDICATOR 

04/10 

CAPITAL  LETTER  J 

10/11 

LOT  ANCU  QUDTATION  MARK 

04/11 

CAPITAL  LETTER  K 

10/12 

NDTSIQN 

04/12 

CAPITAL  LETTER  L 

10/13 

SDPTHYPMENiHaBJI 

04/13 

CAPITAL  LETTER  M 

10/14 

REGISTERS)  TRADE  MARK  SIGN 

Oi/14 

CAPITAL  LETTER  N 

10/10 

MACRDN 

04/10 

CAPITAL  LETTER  0 

11/00 

RRNl  ABOVE.  DEGREE  SIGN 

00/00 

capital  letter  P 

11/01 

PLUS-MdlUS  SIGN 

florat 

CAPITAL  LETTER  0 

11/03 

SUPERSCRIPT  TWO 

00/02 

CAPITAL  LETTER  R 

11/09 

SUPERSCRIPT  THREE 

00/03 

CAPITAL  LETTER  S 

11/M 

ACUTE  ACCENT 

00/04 

CAPITAL  LETTER  T 

11/00 

MICRO  SIGN 

00/00 

CAPITAL  LETTER  U 

11/08 

PIICROWSIGN 

05/00 

CAPITAL  letter  V 

11/07 

MIDDLE  DOT 

00/07 

CAPITAL  LETTER  W 

11/08 

CEDILLA 

00/00 

CAPITAL  LETTER  X 

11/08 

SUPERSCRIPT  ONE 

OO/Oi 

CAPITAL  LETTER  V 

11/10 

MASCULINE  ORDINAL  INDICATOR 

00/10 

capital  letter  Z 

11/11 

RIGHT  ANGLE  QUOTATION  MARK 

00/11 

LEFT  SQUARE  BRACKET 

11/12 

VULGAR  FRACTION  ONE  QUARTER 

00/12 

REVERSE  SOUOUS 

11/13 

VULGAR  fraction  ONE  HALF 

00/11 

RIGHT  OQUARE  BRACKET 

11/14 

vulgar  FRACTION  THRR  QUARTERS 

00/14 

circumflex  accent 

11/1S 

INVERTED  QUESTION  MARK 

00/10 

LOW  UNO 

12/00 

CAPITAL  LETTER  A  WITH  GRAVE  ACCENT 
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ISO  8869-1: 1987  IE) 


TaM*  1  -  leondudMil 


7^  Coda  tabla 


Ml 

cembii 

natlan 

Hama 

13/01 

CAPITAI.  LETTEH  a  WITH  ACUTI  ACCENT 

12/ta 

CAPITAt.  LCTTEH  a  with  cihcumrex  accent 

12/03 

CAPITAC  LCTTEIt  A  WITH  TILOi 

12/04 

CAPITAI.  LCTTBI  A  WITH  OUERESIS 

12/06 

CAPITA!.  LSTTCI A  HATH  mNd  A80V8 

12/06 

CAPITAL  OtPHTHONa  A  WITH  E 

12/07 

capital  LETTER  C  WITH  CEDILLA 

12/08 

capital  LETTER  E  WITH  GRAVE  ACCENT 

12/00 

CAPITAL  LETTER  E  WITH  ACUTE  ACC8IT 

12/10 

capital  LETTER  E  HATH  ORCUMPLEX  ACCENT 

12/11 

CAPITAL  LETTER  E  HATH  DIAERESIS 

12/12 

CAPITAL  LETTER  1  WITH  GRAMS  ACCENT 

12/13 

CAPITAL  LEim  1  WITH  ACUTE  ACCENT 

12/14 

CAPITAL  LETTER  1  WITH  ORCUMPIEX  ACCENT 

12/19 

CAPITAL  LETTBI 1  WITH  OIA0IESIS 

13/00 

CAPITAL  ICELANDIC  LETTER  ETH 

13/01 

CAPITAL  LETTER  N  WITH  TILDE 

13/03 

CAPITAL  LETTER  0  WITH  GRAVE  ACCENT 

13/03 

CAPITAL  LETTER  0 1MTH  acute  ACCatT 

13/0* 

capital  letter  0  with  orcuuplex  accent 

13/09 

CAPITAL  LETTSI  0  WITH  TILDE 

13/00 

CAPITAL  LETTBt  0  WITH  OIAOESIS 

13/07 

MULTIPUCAnON  SIGN 

13/08 

CAPITAL  LETTER  0  WITH  09U0UE  STROKE 

13/08 

CAPITAL  LETTER  U  WRTH  GRAMS  ACCaiT 

13/10 

CAPITAL  LETTEH  U  WITH  ACUTS  ACCaiT 

13/11 

CAPITAL  LETTER  U  VWTH  ORCUMPICX  ACCENT 

13/12 

CAPITAL  LETTER  U  WITH  DIAERESIS 

13/13 

CAPITAL  LETTER  Y  WITH  ACUTE  ACCENT 

13/14 

CAPITAL  ICaAMOIC  LETTER  THORN 

13/19 

SRuu  (KR*4an  unrrei  SHARP  s 

14/00 

SMAU  LETTER  a  WITH  GRAMS  ACCENT 

14/01 

SIMAU  LETTER  a  want  ACUTE  ACCENT 

14/03 

small  LETTER  a  WITH  ORCUMPLEX  ACCENT 

14/03 

SMAU  LETTER  a  yWTH  TRJTS 

t4/Ot 

SIMAU  LETTBI  a  WITH  DIAERESIS 

14/08 

SMAU  LETTER  a  WITH  RWa  A90VE 

14/08 

SMAU  DIPHTHONG  a  VWTH  a 

14/07 

SMAU  LETTBI  c  WITH  CEOIUA 

14/08 

SMAU  LETTER  a  WITH  GRAMS  ACCBIT 

14/08 

SMAU  LETTER  a  WITH  ACUTE  ACCENT 

(4/ TO 

SMAU  LETTER  a  WITH  ORCUMPLEX  ACCBIT 

14/11 

SMAU  LETTBI  a  WITH  OIABIESIS 

14/12 

SMAU  LETTBI  1  WITH  GRAVE  ACCENT 

14/13 

S94AU  LETTBI  1  WITH  ACUTE  ACCENT 

14/14 

SMAU  LETTBI  1  WITH  ORCUMPLEX  ACCENT 

14/19 

SMAU  LETTER  1  WITH  OIACHESIS 

18/00 

SMAU  ICELANDIC  LETTBI  ETH 

19/01 

SMAU  LETTBI  n  WITH  tilde 

19/03 

SMAU  LETTER  o  WITH  GRAMS  ACCENT 

18/03 

SMAU  LETTER  a  WITH  ACUTE  ACCENT 

1V04 

SMAU  LETTER  0  WITH  ORCUMPLEX  ACCENT 

19/09 

SMAU  LETTER  e  WITH  tilde 

ISAM 

SMALL  LETTBI  a  VWTH  OtAEREStS 

19/07 

OlVISiONSIGN 

19/08 

SMAU  LETTER  a  WITH  OBLIQUE  STROKE 

19/08 

SMAU  LETTER  u  WITH  GRAVE  ACCENT 

19/10 

S*4ALL  LETTER  u  WITH  ACUTE  ACCENT 

19/11 

SMAU  LETTER  w  WITH  ORCUMPLEX  ACCENT 

19/13 

SMAU  LETTER  a  WITH  OUERESIS 

19/13 

SMAU  LETTBI  V  WITH  ACUTE  ACCENT 

19/14 

SMAU  ICELANDIC  LETTER  THORN 

19/19 

SMAU  LETTER  v  WITH  DIAERESIS 

Tha  cbda  tabta  <iablt  2)  shoMit  tha  charactefs  Idled  at  the  posi¬ 
tion  in  iha  coda  taWa  conaiponding  to  tha  speaiied  bit  com- 
binaiian. 


Tha  shadad  poaitiont  conasoond  to  bH  combinaiions  that  do 
not  taprasant  gwphic  chaiactata.  ThoiriMaiaoucnda  the  scope 
ol  ISO  8889:  it  is  soadfiad  in  other  Intamaliooal  Standards,  (or 
esamola  ISO  646  or  ISO  6429. 


8  Dasignation  of  tha  charactar  sat 


Tha  graphic  eharactan  of  this  part  of  ISO  8869  eonsmuta  a 
aingia  coded  charactar  sat.  HmrMr,  vnfian  thia  charactar  sot  is 
impiaanantad  together  vsith  other  ceding  standards  such  as 
ISO  2022  or  ISO  4873.  lha  coda  laMa  of  tNs  part  of  ISO  8869 
Shan  ba  eonsidatad  to  conaisi  of  tha  Ie6n«ing  components: 


—  Tha  charactar  SPACE  raprasantad  by  bit  combination 

02/00. 


—  A  94- character  GO  graphic  charactar  sat  raprasantad  by 
bit  combinations  02/01  to  07/14. 

—  A  96-charsctsr  G1  graphic  character  sat  raprasantad  by 
bit  combinations  10/00  to  IS/ 15. 


Whan  required  by  other  coding  staralards.  for  asampla 
ISO  2022  or  ISO  4873.  tha  loSovring  pair  of  aacapa  saquancas 
shaSbousad: 


£50  02/09  04/02 
ESC  02/13  04/01 


to  designate  the  GO  and  lha  Gl  sals,  raspactivalv.  According  to 
ISO  2022.  (ha  charactar  SPACE  does  not  raquiro  dssignsiion. 
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ISO  8859-1: 1987(E) 


Tabis  2  —  Code  table 


[iH 

jjH 

'jHI 

[*BI 

lUI 

!*M 

na 

■Oi 

1  1 

T\ 

o 

EHil 

mm 

mm 

Mi 

■■ 

■■ 

Hfl 

MB 

>BKiH 

ra 

u 

Ui 

Hi 

■■1 

■•1 

HU 

mm 

BH 

BH 

HU 

n 

BllH 

[llBH 

lU 

BH 

Hi 

n 

n| 

Hi] 

■u 

mm\ 

HU 

n 

BH 

■u 

■L'lH 

UB[il 

m^ 

Hbl 

■D 

■BO 

HHlI 

313 

00 

01 

02 

03 

QQ 

05 

06 

07 

08  0 

9  10 

3 

3 

13 

14 

B 

B 

B 

3 

00 

fl! 

H 

SP 

T 

a 

□ 

B 

P 

m 

H 

m 

D 

a 

T] 

B 

B 

B 

1 

01 

m 

■ 

1 

T 

□ 

□ 

a 

q 

m 

IB 

+ 

B 

at* 

N 

0 

a 

B 

0 

1 

0 

02 

n 

It 

2 

B 

R 

B 

B 

B 

IB 

2 

B 

% 

_0_ 

a 

H 

B 

0 

1 

1 

03 

m 

H 

□ 

3 

T 

S 

c 

s 

■ 

ilH 

3 

» 

0 

a 

B 

3 

0 

3 

3 

EB 

M 

HI 

$ 

□ 

□ 

B 

d 

B 

m 

IB 

H 

□ 

0 

B 

D 

B 

fl 

EE 

m 

m 

% 

5 

E 

U 

e 

u 

B 

IQ 

M 

ft 

mg 

0 

3 

B 

D 
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/t 
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■ 
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9 
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3 

08 

■ 

( 

8 

H 

B 

fl 
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91 
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1 

09 
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9 

I 
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fl 
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■ 
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Second 

digit 


First  digit 


a  0 


J,Oi  23456789ABCD 


*p*c.  0  @  P  '  p  A  e 


Q  a  q  A  e 


2  B  R 


3  C  S  c  s  ^ 


$  4  D  T  d  t  N 


%  5  E  U  e  u  0 


&  6  F  V  f 


£  i  V 


§  ¥ 


u  I  fi  q  d 


7GWgwa  6  6l«o 


8HXhxa6®n»y 


y  a  6  ©  TI 


A 


q  u  Q  6 


e  u  /€  ae  CE 


0 


•  liands  for  a  nonbreaking  apace,  the  same  width  as  a  digit 
The  shaded  characters  cannot  normally  be  generated  from  the  Macintosh  keyboard 
or  keypad. 

Figure  1.  Macintosh  Character  Set 

Nonprinting  or  "control"  characters  ($00  through  $1F,  as  well  as  $7F)  are  identified  in  the  table 
by  their  traditional  ASCII  abbreviations;  those  that  are  shaded  have  no  special  meaning  on  the 
Macintosh  and  cannot  normally  be  generated  from  the  Macintosh  keyboard  or  keypad.  Tliose  that 
can  be  generated  are  listed  below  along  with  the  method  of  generating  them: 
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Character  Set  (00  7F)  Quick  Reference  Character  Set  (80-FF)  Quick  Reference 


o 

rN 
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1 

1  4 

•1  Al 

VI 
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B 

B 

B 
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B 

X 

X 
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-t-j 
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OV 

VO 

\$ 

C3 

-O 
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<U 
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V 
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B 
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4.2.0  GENERAL  NOTE  ENTITY  (TYPE  212) 

4.2.9  General  Note  Entity  (Type  212).  A  General  Note  Entity  consists  of  one  or  more  text 
strings.  Eacli  text  string  contains  text,  a  starting  point,  a  text  size,  and  an  angle  of  rotation  of  tlie 
text.  Examples  of  general  notes  are  shown  in  Figure  64.  The  FC  value  indicates  the  font  number 
and  is  an  integer.  Positive  values  arc  pre-defined  fonts.  Negative  values  point  to  user  defined  fonts 
or  modifications  to  a  pre-defmed  font. 


The  following  fonts  are  defined: 


Font 

Duscriptiuii 

0 

Symbol  Font  (no  longer  recommended) 

1 

Standard  Block 

2 

lA:Iloy 

3 

Fiitura 

6 

Comp  80 

12 

News  Gothic 

13 

Lightline  Gothic 

14 

Simplex  Homan 

17 

Century  Schoolbook 

18 

Helvetica 

19 

OCIl-ll  [ISOI073]  (sec  Appendix  J) 

1001 

Symbol  Font  1 

1002 

Symbol  Font  2 

1003 

Drafting  Font  (sec  Appendix  J) 

Pont  U  is  an  old  syiiiliol  font  and  should  no  longer  be  used.  Figure  II  in  Appendix  I  is  a  mapping 
symbol  definition  for  Font  0. 

Font  1  does  not  have  a  defined  display.  Use  of  Font  1  implies  the  receiving  system  may  use  any  font 
wliich  displays  the  appropriate  ASCII  format  characters.  The  intent  of  this  font  is  for  usage  when 
the  actual  display  of  the  characters  is  not  critical  for  the  application. 

Font  19  is  shown  in  Figure  65  and  is  defined  in  Appendix  J  (see  Section  J.5). 

Fonts  in  the  1000  series  display  symbols  mapped  onto  ASCII  characters  as  shown  in  Figures  66,  67 
and  68.  They  do  nut  specify  a  character  display  font.  Font  1003  is  defined  in  Appendix  J  (see 
Section  J.5). 

Table  6  provides  names  for  the  graphical  characters  generated  for  each  valid  code. 

If  the  FC  nimixer  is  not  sufficient  to  describe  the  font,  a  text  font  definition  entity  may  be  used 
to  define  the  font.  If  a  text  font  defniition  i.s  being  used,  the  negative  of  the  pointer  value  for  the 
directory  entry  of  the  text  font  definition  entity  is  placed  in  the  FC  parameter.  The  use  of  the  values 
WT',  HT,  SL,  A,  and  text  start  point  are  shown  in  Figure  69. 

Within  definition  space,  the  parameters  for  the  text  block  are  applied  in  the  following  order  (See 
Figure  70). 

1.  Define  the  box  height  (HT)  and  box  width  (WT). 

The  rotate  internal  text  flag  indicates  whether  the  text  box  is  filled  with  horizontal  text  or 
vertical  text.  The  box  width  is  mcasuretl  from  the  start  of  the  left-most  (first)  text  charac- 
ter/syiiibol  in  the  positive  XT  direction  along  the  text  base  line,  and  extends  to  the  end  of  the 
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4.2.0  GENERAL  NOTE  ENTITY  (TYPE  2*2) 


riglit-mosl  (last)  characler/synilx>l,  extending  N  characlers/syiiiliols  and  N*1  inicrcliaracler 
spaces.  The  box  licigiil  is  ineaanred  in  the  positive  YT  direction  and  is  the  height  of  capital 
letters.  It  is  equivalent  to  the  symbol  “h’*  nseti  in  Appendix  C  of  [ANSI82].  Special  symbols, 
such  as  those  appearing  in  Appendix  C  or[ANSI82],  which  exceed  “h”  in  height  are  centered 
vertically.  Descenders  an«l  |)ortions  of  symbols  exceeding  “h”  extend  outside  the  lower  and/or 
upper  borders  of  the  box.  'I'lie  Imx  height  and  width  arc  measured  Ireforc  the  rotation  angle  (A) 
is  applied.  The  text  start  point  is  defined  as  the  lower  left  corner  of  the  first  character /syml)ol 
box. 

When  a  receiving  system  cannot  lit  a  text  string  inside  its  de/ined  text  box,  it  shall  give 
precedence  to  maintaining  the  full  original  character  height,  as  definetl  by  the  text  box  height. 

2.  The  slant  angle  is  then  applied  to  each  individual  character.  Fur  horizontal  text,  it  is  measured 
from  the  XT  axis  in  a  counterclockwise  direction.  For  vertical  text,  the  slant  angle  is  measured 
from  the  YT  axis. 

3.  'I'he  rotation  angle  is  then  applied  to  the  text  block.  This  rotation  is  applieil  in  a  coimler- 
clockwise  direction  about  the  text  start  point.  'I'he  plane  of  rotation  is  the  XT,  YT  plane  at 
the  depth  ZSn  (where  ZSn  is  the  value  given  for  the  text  start  point). 

4.  The  mirror  operation  is  pcrroriiied  next.  The  value  1  indicates  the  mirror  axis  is  the  (rotated) 
line  perjiendicular  to  the  text  ba.se  line  ami  through  the  text  start  |)oint.  The  value  2  indicates 
the  mirror  axis  is  the  (rotated)  text  base  line. 

Finally,  the  'l>ansrorination  Matrix  entity  is  used  to  specify  the  relative  position  of  definition  space 
within  model  space. 

The  number  of  characters  (NCn)  must  always  be  equal  to  the  character  count  in  its  corresponding 
text  string  (TEXTn). 
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4.2.9  GENERAL  NOTE  ENTITY  (TYPE  212) 


A  SINGLE  LINE  OF  TEXT 


GENERAL  NOTE  ^ 

ith  two  lines 


TX3T  OBHOTiniM 


S3'3 


i.O>i 


3J.0V' 


Hl^iirr  fi-l.  I'.x.Kiiplos  of  llic  Gcn«;r<»l  Nole  Kiiliiy 


4.2.9  GENERAL  NOTE  ENTITY  (TYPE  212) 


The  dcfinilion  of  this  font  can  be  found 
ill  Appendix  J  (see  Seclion  J.5). 


Figure  65-  General  Note  Fniit  19 
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4-2.9  GENERAL  NOTE  ENTITY  (TYPE  212) 


Figure  GG.  General  Note  Foul  1001 


4.2.9  GENERAL  NOTE  ENTITY  (TYPE  212) 


Figure  67.  General  Nolc  Font.  1002 
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4.2.0  GENERAL  NOTE  ENTITY  (TYPE  212) 


The  definition  of  this  font  can  be  found 
in  Appendix  J  (see  Section  J.5). 


Figure  68.  General  Note  Font  1003 
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4.2.9  GENERAL  NOTE  ENTITY  (TYPE  212) 


'I'ahlc  C).  Cliaraclnr  N:iiiics  for  liie  Syiiil>ol  and  Drafling  Fonts 


SyiiiiMil 


Name 


Space 

Excianialioi)  mark 
Quotation  marks 
Pound  sign 
Plus/ininus 
Dollar  sign 
Degree  symbol 
Percent  sign 
Arrifirrsand 
Apostrophe 
I.efl  parenthesis 
Right  parenthesis 
Asterisk 
Plus  sign 
Comma 

Minus  sigii/liyplicn 

Period 

Slash 

Numeric  0 
Numeric  1 
Numeric  2 
Numeric  3 
Numeric  4 
Numeric  5 
Numeric  G 
Numeric  7 
Numeric  8 
Numeric  9 
Colon 
Scnii'Colon 
i.ess  than 
Equal  sign 
C  renter  than 
Question  mark 
Commercial  at 
lJp|)er  casu!  letter  A 
Upper  case  letter  I) 
Upper  case  letter  CJ 
Upper  case  letter  I) 
Upper  case  letter  E 
Upper  case  letter  F 
U  Piter  case  letter  Cl 
Up|>cr  case  letter  11 


) Entries  for  each  Pont  arc  ilccinmi  ASCII  eipiivalent 


Pont) 

1 

loot  1 

1002 

32 

33 

mm 

32 

33 

34 

34 

34 

35 

35 

35 

3G 

.36 

36 

37 

37 

37 

38 

.38 

38 

39 

39 

39 

40 

40 

40 

41 

i 

41 

42 

42 

42 

43 

43 

43 

44 

44 

44 

45 

45 

45 

40 

46 

46 

47 

47 

47 

48 

48 

48 

49 

49 

49 

50 

50 

50 

51 

51 

51 

52 

52 

52 

53 

53 

53 

54 

54 

54 

55 

55 

55 

56 

56 

'56 

57 

57 

57 

58 

58 

58 

59 

59 

59 

60 

60 

60 

61 

61 

61 

62 

62 

62 

63 

6.3 

63 

64 

64 

64 

»i5 

65 

65 

(>6 

66 

66 

67 

67 

67 

68 

68 

68 

69 

69 

69 

70 

70 

70 

71 

71 

71 

72 

72 

72 
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4.2.0  GENERAL  NOTE  ENTITY  (TYPE  212) 
Table  6.  Character  Names  for  the  Symbol  and  Drafting  Fonts  (continued) 


Name 

Symbol 

Fontf 

1001 

1002 

1003 

Upper  case  letter  I 
Upper  case  letter  J 

1 

J 

BZIKI 

73 

74 

see 

App.  J 

Upper  case  letter  K 

K 

75 

75 

75 

for  this 

Upper  case  letter  L 

L 

76 

76 

76 

Font 

Upper  case  letter  M 

M 

77 

77 

77 

Upper  case  letter  N 

N 

78 

78 

78 

Upper  case  letter  0 

0 

79 

79 

79 

Upper  case  letter  P 

P 

80 

80 

80 

Upper  case  letter  Q 

Q 

81 

81 

81 

Upper  case  letter  II 

R 

82 

82 

82 

Upper  case  letter  S 

S 

83 

83 

83 

Upper  case  letter  T 

T 

84 

84 

84 

Upper  case  letter  U 

U 

85 

85 

85 

Upper  case  letter  V 

V 

86 

86 

86 

Upper  case  letter  W 

W 

87 

87 

87 

Upper,  case  letter  X 

X 

88 

88 

88 

Upper  case  letter  Y 

Y 

89 

89 

89 

Upper  case  letter  Z 

Z 

90 

90 

90 

Left  bracket 

1 

91 

91 

91 

Backward  slash 

\ 

92 

92 

92 

lliglil  bracket 

1 

93 

93 

93 

Caret 

• 

94 

94 

94 

Underscore 

95 

95 

95 

Reverse  quote 

t 

96 

96 

96 

Lower  case  letter  a 

a 

97 

Angularity 

z 

97 

Marker/symbol 

X 

97 

Ixiwer  case  letter  b 

b 

98 

Marker/symbol 

01 

98 

Division  symbol 

98 

iMwer  case  letter  c 

C 

99 

Flatness 

o 

99 

I.ess  than  or  equal 

< _ 

99 

Lower  case  letter  d 

d 

100 

Pronie  of  a  surface 

100 

Greater  than  or  equal 

> 

100 

Lower  case  letter  e 

e 

101 

Circularity 

o 

lot 

Marker/symbol 

A 

101 

I.ower  case  letter  f 

f 

102 

Parallelism 

// 

102 

Radical 

n/ 

102 

t Entries  for  cacii  Font  are  decimal  ASCII  equivalent 
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4.2.9  GENERAL  NOTE  ENTITY  (TYPE  212) 


Table  6.  Cliaracler  Names  for  llie  Syniitol  and  Drafling  Fouls  (continued) 


Name 

Symbol 

Foiilf 

1 

1001 

1002 

1003 

iMWcr  case  letter  g 

g 

103 

see 

Cylindricily 

X/ 

103 

App.  J 

Cross  product 

X 

103 

for  this 

Ix>wer  case  letter  li 

h 

104 

Font 

Runout 

/ 

104 

Congruence 

= 

104 

I.owcr  cose  letter  i 

i 

105 

Symmetry 

105 

Not  equal 

105 

Ix>wer  case  letter  j 

j 

106 

Position 

106 

Integral 

/ 

106 

Lower  case  letter  ic 

k 

107 

Profile  of  a  line 

107 

Implication 

D 

107 

(xiwer  case  letter  1 

1 

108 

Perpendicularity 

± 

108 

Union 

V 

108 

Lower  case  letter  m 

m 

109 

Maximum  material  condition 

& 

109 

Intersection 

A 

109 

I.ower  case  letter  n 

n 

110 

Oiariwler 

0 

no 

Approximately  equal 

St 

no 

Ixiwcr  case  letter  o 

o 

111 

All  around  applicability 

0 

111 

Greek  letter  sigma  (Sum) 

E 

111 

I.owcr  case  Idler  p 

p 

112 

Projected  tolerance  zone 

© 

112 

Up  arrow 

f 

112 

iMwer  case  letter  q 

q 

113 

Centerline 

C 

113 

Down  arrow 

1 

113 

I.ower  case  letter  r 

r 

114 

Concentricity 

o 

114 

Right  arrow 

— 

114 

Lower  case  letter  s 

s 

115 

Regardless  of  feature  side 

© 

115 

Ixfl  arrow 

»- 

115 

Ixjwer  case  letter  1 

t 

116 

Marker/symbol 

□ 

116 

Greek  letter  plii 

116 

(Cnlrics  for  Facti  Font  are  deciniai  ASCII  equivalent 
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4.2.9  GENERAL  NOTE  ENTITY  (TYPE  212) 


Table  a.  Ciiaractcr  Names  for  the  Syiiiiioi  and  Drafting  Fonts  (continued) 


Name 


liOwer  case  letter  u 
Mariccr/symbol 
Greek  letter  theta 
l^wer  case  letter  v 
Marker /symbol 
Greek  letter  gamma 
Lower  case  letter  w 
Marker /symbol 
Greek  letter  psi 
I.ower  ease  letter  x 
Markcr/symbol 
Greek  letter  omega 
Lower  case  letter  y 
Marker/symbol 
Greek  letter  lambda 
Ix}wer  case  letter  z 
Marker/symbol 
Greek  letter  alpha 
Left  brace 
Greek  letter  delta 
Vertical  bar 
Greek  letter  mn 
Itiglil  brace 
Greek  letter  pi 
Tilde 
Ovcrscore 


t Entries  for  each  Font  are  decimal  ASCII  equivalent 


Fontf 

1 

1001 

1002 

1003 

117 

see 

117 

117 

App.  J 
for  this 

118 

118 

118 

Font 

119 

119 

119 

120 

120 

120 

121 

1 

I2I 

121 

122 

122 

122 

123 

123 

123 

124 

124 

121 

125 

125 

125 

126 

126 

126 
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APPENDIX  J.5  ADDITIONAL  GENERAL  NOTE  FONTS 

J.5  Adtlitioiial  General  Note  Fonts 

Two  adititioiiai  fonts — Font  19  (OCR*n)  and  Font  1003  (Drafting  Font) — are  defined  for  use  by 
General  Note  Entity  (Type  212).  See  Section  4.2.9  for  more  detail. 

Font  19  (OCR-B)  [ISO1073]  is  defined  in  Figure  Jl. 

Font  1003  (Drafting  Font)  is  defined  in  Figure  J2  and  Table  J2. 


Figure  Jl.  General  Note  Font  19  (OCR-B) 
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BL 

a 

B 
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B 

B 

f 
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B 

© 

! 
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a 

1 
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B 

B 
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a 

z 

B 

B 

N 

■1 
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2 

B 

B 

B 

R 

B 

B 

B 

m 

■1 
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3 

3 
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C 

s 

s 

B 

O 

IB 

© 

a 

S 

n 
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D 

B 

B 

B 

o 

IB 

u 
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% 

5 

5 

E 

E 

u 

U 

B 

o 

— 

* 

h 

a 

6 

B 

F 

B 

V 

B 

zz 

V 

0 

D 

B 

B 

G 

B 

w 

s 

x/ 

V 

B 

( 

n 

n 

8 

B 

H 

B 

B 

B 

X 

T 

) 

n 

9 

9 

B 

I 

B 

M 

B 

-=- 

B 

a 

: 

; 

B 

J 

z 

B 
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Figure  J2.  General  Note  Font  1003  (Drafliiig  Font) 
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appendix  j.5  additional  general  note  fonts 


Table  J2.  Character  Names  for  the  Drafting  Font 


Name 


Space 

Exclamation  mark 
Quotation  marks 
Found  sign 
Dollar  sign 
Percent  sign 
Ampersand 
Apostrophe 
Left  parenthesis 
flight  parenthesis 
Asterisk 
Plus  sign 
Comma 

Minus  sign/hyphen 
Period 
Slash 
Numeric  0 
Numeric  1 
Numeric  2 
Numeric  3 
Numeric  4 
Numeric  5 
Numeric  6 
Numeric  7 
Numeric  8 
Numeric  9 
Colon 
Semi-colon 
Less  than 
Equal  sign 
Greater  than 
Question  mark 
Commercial  at 
Up|>er  case  letter  A 
Upper  case  letter  D 
Upper  case  letter  C 
Upper  case  letter  D  | 
Upper  case  letter  E 
Upper  case  letter  F 
Upper  case  letter  G 
Upper  case  letter  II 
Upper  case  letter  I 
Upper  case  letter  J 


t  Entries  are  decimal  ASCII  equivalent 
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APPENDIX  J.5  ADDITIONAL  GENERAL  NOTE  FONTS 


APPENDIX  J.5  ADDITIONAL  GENERAL  NOTE  FONTS 


Table  J2.  Character  Names  for  the  Drafting  Font  (continued) 


Name 

Symbol 

Pontf 

1003 

Total  runout 

u 

mm 

Straightness 

— 

Hi 

Couiiterbore 

i— J 

118 

Countersink 

V 

119 

Depth 

T 

■  ^9 

Conical  taper 

la 

Slope 

122 

Left  brace 

{ 

123 

Vertical  bar 

1 

124 

Right  brace 

) 

125 

Degree  symbol 

O 

126 

fCntries  are  decimal  ASCII  equivalent 
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ACCENTED  LATIN  CHARACTERS 
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A.3.2  accented  Latin  characters  (ID's  ■  61696  + ) 

TheM  character  iiienlinen  are  rcaenred  for  accented  UUn  letters. 


Note;  For  ease  of  reading,  only  the  low  order  8  binary  biU  of  the  character  idenUfier  number 
it  notated.  Therefore,  pieate  add  the  following  to  each  number  shown: 

OcUh  361000;  DedmaL- 61696;  ilea:  FI 00. 


lUKHTIFIKR 
Octal  Dee  Ilex. 

SIIAIV 

41t 

33 

21 

A 

42s 

34 

22 

A 

43s 

36 

23 

A 

44s 

36 

24 

A 

46| 

37 

26 

A 

46, 

38 

26 

A 

47s 

39 

27 

A 

60, 

40 

28 

A 

61, 

41 

29 

A 

62, 

42 

2A 

C 

63, 

43 

211 

C 

64, 

44 

2C 

C 

66, 

46 

20 

Q 

66, 

46 

2E 

C 

67, 

47 

2F 

f) 

60, 

48 

30 

g 

61, 

49 

31 

e 

62, 

50 

32 

e 

63, 

51 

33 

G 

64, 

52 

34 

G 

66, 

63 

35 

G 

66, 

64 

36 

G 

67, 

65 

37 

G 

70, 

66 

38 

6 

71, 

67 

39 

G 

72, 

68 

3A 

G 

73, 

69 

311 

G 

74, 

60 

3C 

G 

76, 

61 

31) 

G 

76, 

62 

3E 

1 

77, 

63 

3F 

1 

aiARACTKROKStntll'nON 

Grave  A 
Acute  A 
Circumnex  A 

rildeA 

Macron  A 
Breve A 

Diaereaia  A  a  umlaut  A 

lUng  A  a  angitrom  A 
<AMS.AA> 

Ogonek  A 
Acute  C 
Circumnea  C 
High  dote 
Cedilla  C 

Hachek  C  a  caron  C 
llachek  D  a  caron  I) 
Grave  B 
Acuta  B 
Circumflex  E 
Macron  E 
High  dot  B 

Diaeresis  B  a  umlaut  B 
Ogonek  B 

Hachek  B  a  caron  B 
Acute  G 
Circumflex  Q 
Breve  G 
High  dot  G 
Cedilla  G 
Circumflex  H 
Grave  I 
Acute! 
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iniurnnKR 
Octal  Dec  Ilex. 

SHAPE 

aiARACTRR  DESaurntN 

100s 

64 

40 

I 

Circumnex  1 

lOls 

66 

41 

I 

TiUsI 

102s 

66 

42 

I 

Mscrenl 

103s 

67 

43 

1 

High  doll 

llMs 

68 

44 

T 

Oiosrem  1  s  umlaul  I 

106s 

69 

46 

I 

Ogimskl 

106s 

70 

46 

J 

Circumflu  J 

107s 

71 

47 

Cedilla  K 

110s 

72 

48 

L 

Acute  L 

nit 

73 

49 

It 

Cedilla  L 

112s 

74 

4A 

1 

llachefc  L  s  earan  L 

113s 

75 

411 

Acute  N 

IHs 

78 

4C 

ft 

Tilde  N 

116s 

77 

40 

Cedilla  N 

116» 

78 

4B 

ft 

llachek  N  s  caron  N 

H7t 

79 

4K 

6 

Grave  0 

120s 

80 

50 

6 

AcuteO 

121s 

81 

51 

0 

Circumflex  0 

122s 

82 

62 

0 

Tilde  0 

123s 

83 

63 

0 

Macron  0 

I24s 

84 

64 

6 

Oieerem  0  a  umlaut  0 

128s 

86 

66 

6 

Oeubie  acute  0 

128s 

86 

66 

Acuta  11 

127s 

87 

67 

5 

Cedilla  K 

130s 

88 

68 

i\ 

ilechek  11  s  caron  il 

13ts 

89 

69 

S 

Acuta  S 

132s 

90 

5A 

S 

Circumflex  S 

133s 

91 

611 

9 

Cedillas 

134s 

92 

6C 

S 

Ilechek  S  s  caron  S 

136s 

93 

60 

T 

Cedilla  T 

136s 

94 

5B 

t 

lladwkT  3  caron  T 

137s 

96 

6K 

0 

Grave  U 

140s 

96 

60 

U 

Acute  U 

141s 

97 

61 

0 

Circumflex  U 

142, 

98 

62 

0 

riidoU 

143, 

99 

63 

0 

Macron  U 

144, 

100 

64 

0 

llrovoU 

146, 

101 

66 

0 

Oiaereoio  U  =  umlaut  U 
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ASSOCIATION  FOR  FONT 
INFORMATION  EXCHANGE 
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AssocUiion  for 


afli 


Information  Interchange 


Application  for  Assignment  of  a  GlyphID 

Please  answer  the  following  questions  as  best  as  possible.  The  more  information  providetl  the 
more  likely  that  a  correct  registration  of  the  gtypn(s)  can  be  made.  Place  hand  drawn  and 
printed  samples  of  the  glyph  on  the  last  two  pages  of  this  registration. 

1.  Registrant 

Name:  Ronald  J.  Pellar  ( reoreaentative  to  ISO  JTCl/SC2/WG2t _ 

Organization:  Xerox  Corporation  BSAE  322 _ 

Address:  701  S.  Aviation  Blvd. _ 

Gtv:  gl  Seoundo _ 

State,  District,  or  Province  and  Posta/  Code:  California  90245 _ 

Country:  USA _ 

Telephone,  Telex,  and/or  FAX  XT;  (213i  333-7364 _ 


2.  Glyph  name  in  native  language.  Franc 


3.  Glyph  name  transliterated  or  transcribed  into  the  latin  alphabet.  Franc 
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Assodation  for  Font  Infornuliun  Inlorduni’C 


4.  Wliat  script,  alphabet  syilibary,  if  any,  is  liie  glyph  used  with?  Latin  Alphabet 


S.  Wliat  language,  if  any,  is  the  glyph  used  with?  French 


6.  What  category  do  (he  users  of  this  glyph  belong?  (Please  circle  or  underline  choice(s)) 

Mathematics  Linguistic  Tedinical  Other  Monetary _ _ 

7.  Hiis  glyph  is  similar  in  shape  to  what  other  glyph  already  in  (he  registry? 

(ClyphID,  ifaossiblel  The  Latin  Letter  F  ( 000  ( 000 1 000 1 070 1 _ 

8.  This  glyph  is  similar  in  meaning  to  what  other  glyph  already  in  Ihe  registry? 

(ClyphID.  if  possible}  Pranca  (000 1 000 1 239 1 163 1 _ 

9.  Are  there  unic|ue  metrics  associated  with  (his  glyph?  (YES  or  NO)  Yes/No  _ 

10.  Metrics:  (Please  denote  measuring  scheme  and  units)  Pont  dependant _ 

a.  Side  bearings  W/A _ 

b.  Width  Maybe  on  a  figure  width _ 

c  Height  Numeral  Height _ 

d.  Design  size  W/A _ 

11.  Does  this  glyph  vary  in  any  of  the  following  ways,  if  so  how?  Yes _ 

a.  Weieht  Font  dependant _ _ 

l>,  Italic  version  Font  dependant _ _ 

c.  Slanting  Font  dependant _ _ _ 

d.  Scalability  Scalable  like  rest  of  numerala _ 

12.  Is  this  glyph  design  dependant  or  design  transparent,  i.e.,  does  the  shape  change  with  hm 

design?  Design  Dependant _ _ _ _ 
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AssodMion  for  Font  information  Intcrdungc 


13.  Are  there  size  liinilalioiis  on  this  glyph?  (YES  or  NO)  Mo _ 

a.  If  so  what  are  they  _ _ _ 

14.  Dues  this  glyph  exist  in  electronic  formal,  either  bit  map  or  contour?  (YES  or  NO)  Yes 
If  so  where,  what  format,  and  may  it  be  submitted  with  release  for  use  bv  AFII? 

Unknown _ _ _ 


15.  Additional  coinment(s),  or  information  relating  to  this  glyph: 

This  Qlvoh  has  been  designated  as  the  official  monetary  symbol 
Cor  the  french  Franc.  It  Is  used  on  the  new  One  Franc  coin. 


9: 


Association  for  Font  Information  Interchange 


Typical  prinled  sample  showing  the  Cilyph  in  context,  or  typical  use 


Assocuiion  for  Font  fnfornution  Interchange 


_ HF  H 

(MSClIifW 


Hand  drawn  sample  between  H's. 
Try  to  show  relative  height, 
width,  and  placement  of  glyph. 
Add  notes  or  comments, 
if  necessary. 


Handdrawn  sample  of  how  glyf)h  might  be  used 
in  a  (ypii'jt  «  ontext. 


Assodition  for  Font 


l 

Information  Intcrdiange 


GlyphIO  (Decimal) 

New 

Old 

Rev. 

Oen. 

Dale 

^Signauire 

099 

X 

■ 

7/15/88 

Action  Taken:  glyph  assignment.  Dednition'^Hausa  small  letter  K  (Smai 

unvoiced  ejective)”.  Parenthetical  definition  extracted  from  ISO  6438. 


Br  velar 


Application  for  Assignment  of  a  GlyphID 

Please  answer  the  following  questions  as  best  as  possible.  The  more  information  provided  the 
more  likely  that  a  correct  registration  of  the  giyph(s)  can  be  made.  Place  hand  drawn  and 
printed  samples  of  the  glyph  on  the  last  two  pages  of  this  registration. 

1.  Registrant 

Name;  Ronald  J.  Pellar _ _ _ _ _ 

Ori^anization:  Xerox  Corporation _ 

Address:  701  S.  Aviation  aivd. _ _______ 

Glv:  El  Sequndo _ _ _ 

State,  District,  or  Province  and  Postal  Code:  California  90245 _ 

Country:  USA _ _ _ 

Telephone,  Telex,  andlor  FAX  #:  (213)  333~7364 _ _ _ 


2.  Glyph  name  in  native  language.  Unknown 


Z=ZIII=Z==I=Z=Z  I 

3.  Glyph  name  transliterated  or  transcribed  into  the  lalin  ainhabet.  Unknown _ _  ^ 

-  — . .  Z  I 
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Assoaauon  tor  tont  Inlormaiion  Inlerdunf’C 


4.  Wlut  script,  alphabet/ syiUbary,  if  any,  is  the  glyph  used  with?  Latin  Alphabet 


5.  What  language,  if  any,  is  the  glyph  used  with?  Hauaa 


6.  What  category  do  the  users  of  this  glyph  belong!  (Please  circle  or  underline  choicels)) 

Mathematics  Linguistic  Technical  Other _ 

7.  Tills  glyph  is  similar  in  shape  to  what  other  glyph  already  in  the  registry! 

(ClyphID,  if  possible)  The  Latin  Letter  k  f  OOP  1 000 1 000 !  107) _ 

8.  This  glyph  is  similar  in  meaning  to  what  other  glyph  already  in  the  registry! 

(ClyphID,  if  possible)  The  Latin  Letter  Ic  (000 1 000 1 000 1 1071 _ 

9.  Are  there  unique  metrics  associated  with  this  glyph!  (YES  or  NO)  No _ 


10.  Metrics:  (Please  denote  measuring  scheme  and  units)  Font  dependant _ 

a.  Side  bearings  Same  as  Latin  letter  k. _ 

b.  Width  Same  aa  Latin  letter  k. _ 

c.  Height  Same  aa  Latin  letter  k. _ _ 

d.  Design  size  Same  as  Latin  letter  k. _ 

11.  Does  this  glyph  vary  in  any  of  the  following  ways,  if  so  how!  Yes _ 

a.  Weight  Pont  dependant.  Same  aa  Latin  letter  Ic. _ 

b.  Italic  version  Font  dependant.  Same  aa  Latin  letter  k. _ 

c.  Slanting  Font  dependant.  Same  aa  Latin  letter  k. _ 

d.  Scalability  Scalable  like  rest  of  alphabet. _ 

12.  Is  this  glyph  design  dependant  or  design  transparent,  i.e.,  does  the  shape  change  with  im 

design!  Design  Dependant _ _ _ 
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Assoaiiion  for  Font  Information  Interchange 


13.  Are  (here  size  limilalions  on  this  giypit?  (YES  or  NO)  No 
a.  If  so  what  are  they  _ 


14.  Does  this  glyiih  exist  in  electronic  formal,  either  bit  map  or  contour?  (YES  or  NO)  Yes 
If  so  where,  what  format,  and  may  it  be  submitted  with  release  for  use  hy  AFIIt 

This  Qlvph  can  be  obtained  In  Ikarus  Cormat  and  the  letter  it 
represents  is  In  the  public  domain. _ _ _ 


15.  Additional  commends),  or  infomiation  relating  to  this  glyph: 
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Assocution  lor  Font  Information  Interchange 


Large  printed  sample 


IIAUSA  (LalioKripl) 

Haiua  is  the  second  most  widely  spoken  language  in 
Africa.  In  Nigeria  alone  it  is  probably  spoken  and  under* 
stood  by  ten  million  people. 

It  is  written  in  Latin  script,  using  the  following  special 
letters:  6  rf  L 

SPCCIMCN  This  is  part  of  a  Hausa  foik-tale: 

Wannaa  wani  mutuni  ke  nan,  ra&umara  ta  8ace.  Sai 
u  kama  hanya,  tana  laflya.  Tana  tafe  tana  figar  ganyen 
iiace,  tanacL 


Typical  printed  sample  showing  the  GIyi)h  in  context,  or  typical  use 


Association  for  Font  Information  Interchange 


Hand  drawn  sample  between  H's- 
Try  to  show  relative  height, 
width,  and  placement  of  glyph. 
Add  notes  or  comments, 
if  necessary. 


Hand  drawn  sample  between  /s. 

Try  to  show  relative  height, 
width,  and  placement  of  glyph. 
Add  notes  or  comments, 
if  necessary. 


Handdrawn  sample  ol  how  glyph  might  be  used 
in  a  typical  context. 
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EXAMPLES  OF  TYPOGRAPHIC 
QUALITY  FONTS  FROM  ITC 
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I 

I 


APPLE  LASER  WRITER  FONTS 
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Ill 


System  Rcquireniciils 


Tcduiicai  SpeciAcatiofu 


To  IKK  llie  Apple  LaserWkiicr  ^  OneormseMannioah 

IlHnprinla;  you  iiua  lave  one  (ininiaiumSI2K(^RAM)iv 
(/(iKsesyalcnB;  Apple  Iks  ainipuieBUjnatt.1* 

cd  vbthe  lixafralk  Caiding 
System. 


Marking  engine 

^  Guiun  liiP-SX  bser 

seniKPpiw; 

nroccssor 

►  Mis««)b<'iHU20  (16.67- 
megilieia  ckxk  speed) 

Memory 

^  I  iiie^iyie  KOM; 
2niepiiytesKAM 

Inur&ces 

^  .S(2I,  AfipieTalk.  Apple 
Deskiop  llus'  (for  future  expon- 
siHi),  and  ICi-232-C  pons 

Expansion  capabilities 
»  KUM  expansiiin  via  fus- 
expansiun.<iJia 

>  KAMexpansknupUil2 

impliyHs 

^  HxlemaiSG3'portrwhaid 
dskAmi  storage 
^  Apple  Diskiop  Dus  fur  future 
exponsiun 

Print  quality 

»  AUiextandgrapiikspreued 
at  300  Ity  JOO  (ku  per  in^ 
ftiUiage 


Built-in  foot  familin 
^  Tsms,lleivciica,Gunei; 
Symisii,  rre  Avant  CkudeGtahk, 
riC  Ikniunan,  New  (jentuiy 
StixKilKaik,  1  kdwtia  Nanuw, 
Palattnix  rrCZapfOanceiy, 
andfTCZapfD^ats  / 

Speed 

^  8  pages  per  minute  natti- 
irnun  thruughpiH  (aoial  speed 
depends  on  nages  printed) 

Moling  pntooois 
>  DtHSt7ipi,asuhBCioftiie 
Diaiiio 630 amnand  set,  and 
Ik-wktt-l’adanl  lase^ei  t*lus 
enadatiun 

^  - - t-a  - 

mB  oMcnui 

^  |jeUei;le|pl,A4,andRS 
soes,  using  I6>  to  20fiwnd 
.ungie-shcei  phoHxopy  Iwnd, 

M>  to  S^miikI  leiterii^  and 
CDkired  stttck,  cvuansparency 
(weritead  film,  iirivdo^ 
blxis,  and  paper  (up  to  36- 
pound)  supponed  via  manual 
feed.  Envehipes  also  supponed 
va  opiionai  envdope  tray. 


w  AnMS-nOSurG6/2a]ni- 
puter  wsh  a  LocafTalk  rc  Can 
or  an  RS-232-C  cdiieand  ap- 
pnpriatesidtware. 

^  Anycshercomputerwiihai 
ilS-232-C  cdile  and  appropriai 
software: 


Mmcapadiks 

w  Paper  casetteslmid  200 
siieea  of  2Apuund  paper 
^  Envekipe  cassette  liukb  15 
enveiupes. 

Mnuhlr  saiftMe 

>  LoiersaelLOIty  10.5 
indies;  legak  8.0  liy  13.0  intiiu' 
A4:7.4lliy  I0i)6  kwhs;  1)5; 
7i9liy  10.16  indies  (acnai 
piintahle  ana  may  vaiy 
depending  on  application) 

Sfae  and  weight 

^  Ileig|S:8.6in.(2lJ)cm) 

»  VI1dlli;20in.(50iicm) 

Vail  letter  uay  attached,  26.4  ir 
(67.1cm) 

^  Depth:  1&5  in.  (47  cm) 

^  V(l-iglH:45lli.(20L25kg) 

Opentlng  enviraoment 

>  Temperature:  50*  to  90"  F 

(10"to3rO 

>  Humidiiy:  20  peicent  to  HO 
perevrt 

Power  requirements 
^  90to  l26vultsAC; 
50to60lienz 


Ordering  information 


Apple  LaserWriter  Unr  With  ynurraderyouH  receive;  ^  LarerWriierlllnsiallaiKmdis. 

OnlerNo.  M(t2l5  ►  laserWHier  Unix  primer  ►  Ijettercasieiie 

w  lascrWrilcr  IlNr/NR  Rmss  ^  Toner  caitridge 

disk  >  Owner’s  guide 

^  limiied  wananiy  statement 
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HP  LASER  JET  FONTS 
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•  LaserJet  SOO  PLUS:  Job  orfselting  can  be  used 
between  jobs  to  allow  for  easy  job  separatioa 

Printable  Oiamcters-Per-Line 
Pitch) 


PrM 

PertraN/Landacapa 

Pitch 

Sid. 

Ugal 

A* 

ea 

10 

80(106 

80/138 

n/112 

86/97 

12 

98/127 

98/183 

03/13S 

80/118 

18.66 

132/178 

132/228 

129/188 

111/167 

Printable  Lines-Per-Page 


Lfem/ 


PwlraH/LandaMp* 


Ineh 

Sid. 

Legal 

A4 

as 

8 

82/48 

80/48 

88/48 

56/39 

8 

84/83 

108/63 

89/81 

78/S2 

Printable  Surface 


VWdlh;  tnohaa 

aid. 

8.0 

Legal 

8.0 

A4 

7.8 

85 

8.7 

MM 

203 

203 

198 

170 

Langih:  Inehea 

10.0 

110 

11.3 

9.7 

MM 

289 

345 

287 

247 

Power 

•  Voitage/Frequencies 
I  l5V-»-/*iO%  60Hz 

•  Optional: 

220V+/-10%  50Hz 
240V+/-10%  50Hx 

•  Power  Consumption  at  1 15  VAC 

850  Watts  Printing  Maximum  (2900  0TU/Hr) 
170  Watts  SUndby  (580  BTU/Hr) 

Environmental 


Temperature  (Printer  &  Cartridge) 
Operating 


Storage 

Altitude 

Operating 


10  to  32^  degrees^ 
(50  to  91  degrees  Fp 

0  to  35  degrees  Cl 
(32  to  95  degrees  F.)' 


0  to  Z^OO  metres 
(0-8  JOO  Tcet) 


Audible  Noise 

Printing  <  55  dD(A)  SUndby  <  45  dOt/ 

Note:  Meaeuted  one  mater  (rom  eouree  aceorcSiq  lo  ISO/OIS  777 

Physical  (LaserJet  and  LaserJet  PLUS) 


Width 

Depth  (body  only) 
Depth  (with  trays) 
Height 
Weight 


47^  cm.  ( 1 8J  inche: 
413  cm.  (16.2  inche: 
723  cm.  (283  inche 
293  cm.  (1 1.4  inchr 
32  kg.  (71  pound 


Physical  (LaserJet  500  PLUS) 


Width 

Depth  (body  only) 
Depth  (with  trays) 
Height 
Weight^^ 


473  cm.  ( 1 83  incite: 
493  ent  (193  inche 
87.5  cm.  (34.4  inche 
46.0  cm.  (18.1  inche: 
43  kg.  (94  pound. 


LaserJet  Printer  Font 
Product  Summary 

Soft  FonU 


Ask  your  IIP  Dealer  or  Sales  Rcprcsciiintive  Tor  the 
latest  information  on  soft  fonK  Disc-based  soft  font: 
can  be  used  with  the  LaserJet  PLUS  and  LaserJet  SOO 
PLUS  printers  only. 

Font  Cartridges  (Currently  Available) 


92ZB«A 

mma 

msec 

922880 

92286E 

922 86F 

922800 

92288H 

9228ej 

92288K 

9228eL 

92280M 

92288N 

92288P 

922880 

92288fl 

92208T 

92288U 

92288V 

92288W 

92288X 

92288Y 


Ceurler  1 

Tma  Proper  llonel  1 
liUertteUorteT  I 
PreeWpe  aie 
Letter  QoMb 
Tme  Preperllenal  2 
Lepetaie 
Le^  Courier 


MaUt  Tme 

Courier  PoilraM  mnd  LetWeeei'e 
PreeWge  ate  PorIraH  and  Lmdtcape 
Letler  OolHo  PerliaN  and  Landteaiie 
Tma  nmn  PorlraN  and  Landacape 
1 


PraeantsUona  1 
Tea  1 

Forma  Portrait 


Oar  Code  3  ot-OTOCR-A 
Bar  Coda  EAN/UPC  and  OCR-B 
PC  Courier  I 


Non-operating 

Humidity 

Operating 

Non-O|temiing 


0  to  1 5.000  metres 
(0-49300  feet) 


20  to  80%  RH 
10  to  80%  RH 


For  lottf  prv*  tamulee  and  other  lent  mlormsllon.  ttk  your  HP 
Daalar  or  Salae  Rapraaanlallva  lor  Ilia  Latai  Jal  Prailar  Fani 
Carltidpa  Satecllon  Oulda,  pari  manhar  5954.2270  (or  Mtk  lo  lea  the 
LaaarJot  Pikiter  FamSy  Font  Catalog,  pail  no.  5954-2277). 

Font  earirldgaa  and  ditet  are  mkktilo  llireiigh  yoiir  HP  Oamw  or 
thioiigli  HowKill.Pacliatd't  OIracI  MaifcellOQ  UlvHlen  Cak  lok  liaa 
800.538.87B7  (m  CaSlornla  ca«  408.738-4133  coaecl) 
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I 

\ 

\ 

TIte  fallowing  table  indicates  tlie  character  sets  available  on  each  of  the 

I  three  fonts.  The  character  seta  on  the  same  line  (such  as  0,  10,  and  20) 

have  the  same  characters  for  each  decimal  code.  These  sets  are  illustrated 
on  the  next  page. 


Character  Se 


'7610A/'7660A/ 

»7670A/»76«0A,B/ 

37585A,B/7586U/759XA 

»7680B/»7S85B 

768aB/759XA 

Character  Set 

ISO 

Registratior 

Number 

Fixed-Space 
Vector  Font 

Variable-Space 
Arc  Font 

Fixed-Space 
Arc  Font 

0 

10 

20 

ANSI  ASCII 

1 

11 

21 

HP  9825  HPL  Character  Set 

2 

12 

22 

French/German 

... 

3 

13 

23 

Scandinavian 

— 

4 

14 

24 

Spanish/Lntin  American 

— 

5 

15 

25 

Special  Symbols 

— 

6 

16 

26 

JIS  ASCII 

014 

7 

17 

27 

Roman  Extensions 

— 

8 

18 

28 

Katakana 

013 

9 

19 

29 

ISO  IRV  (International 
Reference  Version) 

002 

30 

40 

50 

ISO  Swedish 

010 

31 

41 

51 

ISO  Swedish  for  Names 

Oil 

32 

42 

52 

ISO  Norwegian  Version  1 

33 

43 

53 

ISO  German 

021 

34 

44 

54 

ISO  FVench 

025 

35 

45 

55 

ISO  British 

004 

36 

46 

56 

ISO  Italian 

015 

37 

47 

57 

ISO  Spanish 

017 

38 

48 

58 

ISO  Portuguese 

016 

39 

49 

ISO  Norwegian  Version  2 

061 

60 

70 

80 

ISO  French 

069 

99 

— 

— 

Drafting 

— 

100 

— 

— 

Kanji 

— 

101 

— 

— 

Kanji 

— 

-1 

— 

— 

Downloadable  (userdefined) 

— 

'Chaiactar  mu  60, 70. 99, 100, 101,  and  •!  not  impUnunud  on  (h«  7SIOA  and  7580A. 

■VanablMpaea  are  font  and  ur  aau  60  and  -1  not  impianianUd  on  lha  7S70A. 

‘All  7S80A/7!yiSA  ploUara  and  7580B/7585B  ploUan  with  aarial  prafia  nambar  2309,  2331,  2334.  and  2335  conUin  only  character  sr 
O-.'S  und  lO-IS.  758XB  pioUera  with  aarial  preTu  iiumbor  2402  and  highor  conUin  ail  characUr  aaU (axeept  39, 60, 100,  and  lUl)  in  ^ 
thna  fonta. 
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Fonts 


TIMES  ROMAN 

ABCDETGIIUKLMNOPQRSTUVWXYZ 

abcdefghijklinnopqnluvwxyzAAKEOiicaflCfAilTnflniini 

01234567g9V4y4'A/j;^.;:!?0(K}A-|"“"U - ttSl* 

@e9'*Sc£/#%X*  «+±><'" 

LUaOA 

ABCDEFCHIJKLMNOPQRSTUVWm 
abcdefgliiJklinnopnrstuvwxyz&>CCE0aa!oe&CcA4frnnfnnii 
0 1 23456789‘/«*AHA^i7()[l(l  AJ""d - 

©ow-SCEfiTtJt.  - «>€»+— ±><-*«a- 

CENTURY  SCHOOLBOOK 

ABCDEFGHUKLMNOPQRSTUVWXYZ 
•bcderghijkliniiopqntuvwxycSt4E(E0MBaBaQ(AAnnfl(n{Ri 
01234667a9!i«»V-..;:!?()tl{>A4"“a - .ttSl* 

—H— K+tx— 


HELVETICA 

ABCDEFGHUKLMNOPQRSTUVWXYZ 
abcdelgM|ldinnopqretiivwxyz&^(£0aaacaBQcAdffnn(nfn 
0123456789 ’A  y4  VW-..^l70n{}A-|”**il - tt§7* 

LUaOASANS 

ABCDEFCHIJKLMNOPQRSTUVWXYZ 

abcdefghijklmnopqrstiivwxyz&>ea0«Me&CcAiff6nfnff 

0 1 23456789K104/- J70 II fl AJ~il -  till* 

9e«<-5<£f«XXi'** -  •wM— x+±><'“*a— 


ProprietoiT  Custom  Fontt»OpHonal 


niiniSUa 

B 

B 

a 

9 

B 

B 

s 

B 

B 

20 

R 

B 

IB 

LUCIOA*  Raman.  Bald,  luUe  isaowniaw 

B 

B 

• 

o 

B 

B 

fl 

o 

B 

B 

1 

fl 

• 

LUaOA  SANS'*  Romaa  Bald,  nolle  mamrnmmmmt 

B 

B 

O 

o 

B 

B 

B 

• 

B 

B 

o 

B 

B 

• 

• 

H 

H 

H 

H 

H 

m 

H 

B 

H 

H 

11 

H 

H 

H 

H 

* 

■ 

* 

TIMES  ROMAN*  Romm,  0«U« //Wic  iMOMnnmwi 

B 

B 

B 

• 

a 

O 

# 

B 

B 

B 

• 

o 

B 

B 

• 

CENTURY  SCHOOLBOOK*  Roman,  OoU.  Italie,  Raid  tlaUo 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

• 

o 

B 

B 

• 

PI  SYMBOLS  IIOOnmmiMMi 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

• 

o 

B 

B 

’l«p«  4v4il4bl*  in  ROMAN  only 


Standard  Fonts 

Couriar  1 S  pitch 
Courlar  12  pibch 
Courier  10  pitch 
Courier  8  pitch 

Couziaz  Bold  12  pitch 
Courier  Bold  10  pitch 

Dotvnloadablc  Fonts  Available  at  No  Cost 

Our  UNIX  support  tape  provides  17  complete  sets  of  public  domain  fonts  which  have  IS  different  point  sizes  (6  7, 8  9  10  It  T 
14, 16. 18,  20,  2Z  24.  28.  J6).  We  also  provide  a  number  of  partial  sets  for  over  890  different  font  files. 

Our  VAXlVMS  TfX  support  tape  provides  over  70  different  Metafont  fonts  which  allow  you  to  uenerale  addilioiial  sizes 
and  fonts. 


Couziaz  Chazactaz  sat:  177 

ABCDEFQIXJKLMNOPORSnmnCYZ 
abedafghi jklsnopqzstuvwxyz 
01234S6789$eci%l;.V' 

SJBI0aitn&inuk  % 


nsi*(acr'"'''. - gAi?* 

IROOOUlAaafil IRouuU 
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PostScript— PostScript  is  a  page  description  language  that  Is  compact,  universal,  coi^nient, 
portable  and  flexible.  It  differs  in  a  very  fundamental  way  from  ail  otlier  page  description  Inni^iages. 
Namely,  a  PostScript  description  of  a  page  is  an  executable  program  in  a  grapliics  pnjgrammiiig 
language,  rather  than  being  data  input  to  some  page  formatter.  Like  any  complete  programming 
language,  PostScript  has  operators  and  operands,  variables  and  constants,  a  syntax  and  a  semantics, 
and  a  customary  usage  style.  Unlike  most  programming  languages,  it  also  has  po^rfui  graphics 
primitives  that  underlie  a  uniform  and  consistent,  device-indq^endent,  graphics-imaging  model. 

TVansformatlons  on  Text  and  Graphics— QMS-I’S  800  allows  text  and  graphics  to  lie  scaled  and 
rotated.  The  full  generality  of  two-dimensional  matrix  transformations  is  available.  Scale,  rotate  and 
translate  primitives  exist  in  the  language,  but  oth^  transformation  specifications  can  be  built  up. 

Synthetic  Halftone  Text  and  Graphics— QMS-PS  800  provides  capabilities  for  syntlietic  halftone 
text  and  graphics.  Graphic  shapes  and  text  can  be  filled  with  halftone  color  or  gray  values.  All 
parameters  of  the  halftone  process  (spot  shape,  orientation,  screen  frequency  and  transfer  functioir 
may  be  specified  by  the  user. 

Arbitrary  Clipping  of  Text  and  Graphics— With  the  QMS-PS  800,  the  u.ser  can  .specify  arijitrary 
clipping  boundaries  for  text  and  graphics.  PostScript  can  crop  any  text,  graphics  or  scanned  image  Ic 
its  clipping  region. _ _ _ 

'^^EFACES 

With  the  QMS-PS  800,  you  have  typefaces  that  include:  Times,  Times  Bold.  Times  Bold  Italic,  Helvetic 
Helvetica  Bold,  Helvetica  Oblique,  Helvetica  Bold  Oblique,  Courier.  Courier  Bold.  Courier  Oblique, 
Courier  Bold  Oblique,  as  well  as  Symbol,  Underline,  Sliadow  and  Hollow  Styles  for  all  resident 
typefaces.  They’re  scaleable  from  four  points  upward  and  can  be  rotated  to  any  orientatiom^^.,-^ 

GRAPHICS 

Generate  circles,  graphs,  pie  and  bar  charts,  letters,  logos,  and  tran.sparencies  for  business.  Intricate 
three-dimensional  perspective  plots  for  engineering.  High-quality  forms  and  documents  with  multipi 
typefaces.  And  phototy^etting  simulations  for  electronic  publishing. 

PRINTSPEED 

Eight  pages  per  minute.  Actual  printing  speed  depends  on  application. 

PRINTER  SPECIFICATIONS 

TYPE— Desk-top,  electronic  page  printer. 

PRIIMT  METHOD— Raster  scan  semiconductor  diode  laser  beam  with  rotating  polygon  mirror  and 
lens  deflection  onto  photoreceptor,  xerographic  image  transfer  to  plain  paper. 

PRINT  SPEED — Eight  pages  per  minute.  Actual  printing  speed  depends  on  application. 

LASER— Semiconductor  laser  scanning  .system. 

TONER— Dry,  monocomponent  in  user-replaceable  cartridges. 

PAPER— x  11”;  8yi”  x  14";  A4  (international);  B5  (international);  envelopes,  charts.  Iransparei 
cies  (manual  feed);  minimum  weight- 16  lb.s.;  Maximum  weight-24  lbs. 

PAPER  LOADING— Cassette.  100  sheets  each. 

DOT  PITCH— 300  dots  per  inch  horizontal,  300  dots  per  inch  vertical. 

WARM-UP  TIME— TWo  minutes  from  cold  start. 

ELECTRICAL  REQUIREMENTS -Printing-0.8  KVA;  StandbyO.3  KVA 
OPERATING  ENVIRONMENT- 50-90'’F(10-30”C);  Humidity  20-80'r. 

RECOMMENDED  USE  LEVEL- Up  to  3,000  pages  per  month. 

DIMENSIONS- 18.7”  (W)  x  11.4”  (H)  x  16 J”  (D). 

WEIGHT-6.5  lbs. 

NOISE  LEVEL- Less  than  .55  dBA. 

STANDARD  HOST  INTERFACES -RS232.  RS422  and  AppleTalk™  ijort. 

MEMORY  REQUIREMENTS -2M  RAM  and  .5M  ROM. 
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Bitstream® 

Fontware'“ 


lypeface  Packaga 
Ordar  Fonn 


(Pkutfirmll 

NaM 

im 


CiitLSUM.2ipCadi  ~  CoMiint 

Ship  To  (il  dilletent  irom  above) 


Oy.  SUM.  24  Com 


CMMiy 


Ti  Order  Order  No. 

Please  comolete  this  form  and 

mad  to  Bitstream  Ick.  FTP-A1 

Order  by  Phono:  800-522-386S 
to  Maaacinmito:  6I7-497-7912  FTP-A3 

FTP-A4_ 

FrP-A5_ 

nP-A6  ‘ 

FTP-A7  ’ 

FTP-AB  ” 

FTP-A9 

FTP-A10 

FTP-AD  ' 

FTPA12 

FTP-A)3 

FTP-A14 

FTPAI5 

RP-A16 

FTPA17 

FTP-A18 

FTP-A19 

FTP-A20 


T\rptlaco  Pachato  Naow 

Swiss 

Century  Schooi^k 
Dutch 

Zap!  Calligraphic _ 

Futun  Light  _ 

Swiss  LighI  _ 

Swis  Condotsed  _ 

Future  Book 
Futura  Medium 
Courier  (to  Pitch) 

Letter  Gothic  (tZ  Pitch) 

Prestige  (t2  Pitch) 

ITCAvani  Garde 
Zap)  Humanist 
ITC  Garatnond 
ITCSouvemr 
HCKonma 
Bitstream  Charter 
ITCGalliard 

Headlines  t :  Bitstream  Cooper  Black  •  Broadway 
University  Roman  •  (Roister  Black 


Qaaality 


Price:  $195.00  each 
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S  EYB  0  LO. 
SANTA  CLARA. 
CALIFORNIA. 
SEPTEMBER 
9  -  12  1  9  8  7. 


Bitstream 

Fontware 


Fontware 

Typefaces 

Mm 

CMinf  Sdiooibook 
Outeii 

Zipf  CalOgnplde 
Fiitm  UgU 
MmUoM 
Mm  CodMwrt 
Fahn  Book 
FOtara  MMiHa 
CoortM  (10  plU) 

Lite  Gsttie  (12  pflcbl 
Pmtiga  (12  pHeii) 

ITC  Amt  Garda 
ZapI  Humaaiit 
ITC  Garanaad 
lie  Soonair 
nc  Korian 
BBsirtaa  CAartar 
ITC  GatBard 
HaadBaa  1: 

Caapar  Black 
Broadway 
Uahtofiky  Raoiao 
ClaWar  Black 


About  BHsiroam  Fontware  for  Your  PC 


Based  in  Cambridge,  Massa- 
diusetts.  Bitstream  was  the 
first  independent  digital  type 
foundry.  Founded  by  a  pces- 
dgious  group  of  typographic 
professionals.  Bitstream  has 
grown  rapidly  to  a  team  of 
75  expert  type  designers, 
softwm  engineers,  as  w^  as 
mariceting  and  customer  sn^H 
port  professionala. 

An  industry  leader  in  typo* 
graphic  quality  and  innova* 
dye  technology.  Bitstream 
supplies  digital  type  and 
related  software  to  200 
equipment  manuEactnrers 
and  software  developers 
throughout  the  world.  That 
means  you  see  Bitstream  type 
every  day,  everywhere:  in 
newspapers,  magazines, 
book^  television,  video  and 
business  documents. 


For  More 
Information: 

Bitstream  sales  will  assist  you 
in  getting  the  typeface  of 
your  dioice,  compatible  with 
your  desktop  publishing 
system.  Call  Bitstream  at 
800-522-3668. 


Fontware  is  the  first  program  that  makes  fonts  on  the  IBI 
PC/AT  or  compatible  in  virtually  any  size  for  most  popu 
displays  and  printers  6om  typefoce  padages  comprising 
the  Fontware  libcary.  Fontware  Insafiadon  Kits  are  tmi. 
able  for  Ventura  Publisher  and  for  Microsoft  lAfindows 
appllcadons,  among  mote  to  come. 

Fontware  gives  you  professional  typographic  quality  and 
variety  so  you  can  the  most  of  desloop  publidiing. 
And  sinoe  Fontware  creates  matching  screen  and  printer 
fonts,  you  can  preview  your  document  accurately  before 
you  print  it 


Industry  Leaders  Endorse  Fontware 

Finl  Biaioetd,  Rresident  of  Aldus  Gotpotadon  said, 'Having 
been  a  part  cf  die  evoiudoa  of  Fontware  over  the  last  18  mom 
vae  know  that  the  font  requirements  ofour  PC  PageMaker  cm 
tomeawiDbe  realized  duBiks  to  Fontware.*  Bitstream’s  new 
product  allows  for  matching  soeen  and  pdnter  foots  and  oom- 
piete  oootioiower  type  foots  aixl  diatacter  ai^usanents,  vdiich 
was  not  available  for  die  PC  until  Fontware: 

Ventura  Software  has  been  wodcing  with  Bitstream  to  create 
Fontware  for  Vemnra  PuUhher.  The  result  is  a  product  wfaid 
provides  exBct^  die  oqtabilities  diat  desktop  puUishing  users 
have  been  add^  foe  fieedom  to  choose  any  type  size,  true 
WYSIWYG  rapahflity,  device  independence  and  a  large,  ptofc 
sionalquality  type  libcary,”  said  John  H.  Meyer,  Presidem  of 
Ventnta  Softw^  Inc 
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3  Selecting  and  Controlling  Fonts 


Hewlett-Packard  has  standardized  the  typefaces  in  Figure  3.4: 


Value  of  T 

Typeface 

0 

Line  Printer 

1 

Pica 

2 

Elite 

3 

Courier 

4 

Helvetica  (HELV,  Swiss) 

5 

Times  Roman^  Dutch  (TMS  RMN) 

6 

Gothic 

7 

Script 

8 

Prestige 

9 

Casion 

10 

Orator 

11 

Presentation 

12 

Helvetica  Condensed 

14 

Futura 

15 

Palatino  (21apf  Calligraphic) 

16 

Souvenir 

17 

Zapf  Humanist  (Optima) 

18 

Garamond 

19 

Cooper 

20 

Coronet 

21 

Broadway 

22 

Bodoni 

23 

Century  Schoolbook 

24 

University  Roman 

25 

Avant  Garde  Gothic 

27 

Korinna 

28 

Bitstream  Charter 

29 

Ooister  Black 

30 

Galliard 

136 

Futura  Book 

146 

Futura  Light 

148 

i 

Helvetica  Light 

Figure  3.4 


Hewlett-Packard  Typeface  Designations 
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Appendix  B  -  Font  List 


Font 

Index 

Abbreviation 

FONTl 

001 

FONT2 

002 

FONT3 

003 

FONT4 

004 

SWSR 

006 

SWSI 

007 

GOTBC 

008 

SWSB 

010 

DUTR 

on 

Dun 

012 

SQRBX 

013 

SQRX 

014 

CLRL 

015 

BODB 

017 

BODBI 

018 

swsc 

019 

SWSBC 

020 

SWBU 

021 

SWBL 

022 

GMFL 

023 

GMFH 

024 

ZHDI 

025 

SWSH 

026 

SWSBK 

027 

FRTZQ 

028 

FRZQB 

029 

CNSCH 

030 

CSCHB 

031 

ZHDIB 

032 

SWSBO 

033 

BRSH 

034 

GARL 

037 

GARB 

038 

GARBD 

039 

PI2 

098 

Bitstream  Name 


(like)  Gothic  73 1  Bold  Gothic 

(like)  Swiss  721  Bold  (Helvetic  Medium) 

(like)  Clarendon  701  Clarendon  Light  [Craw  Clarendon] 
(like)  Swiss  721  Roman  LHelveiicl 

Swiss  721  Roman 
Swiss  721  Italic 
Gothic  731  Bold  Condensed 
Swiss  721  Bold 

Dutch  801  Roman 
Dutch  801  Italic 
Square  721  Bold  Extended 
Square  721  Extended 

Qarendon  701  Clarendon  Light 
Modem  421  Bodoni  Bold 
Modem  421  Bodoni  Bold  Italic 
Swiss  742  Condensed 

Swiss  722  Bold  Condensed 
Swiss  742  Bold 
Swiss  742  Light 
Geometric  21 1  Futura  Light 

Geometric  211  Futura  Heavy 
Zapf  Humanist  601  Demi 
Swiss  721  Heavy 
Swiss  721  Black 

Flarcscrif  861  Friz  Quadrata 
Flareserif  861  Riz  Quadrata  Bold 
Century  702  Century  Schoolbook 
Century  702  Century  Schoolbook  Bold 

Zapf  Humanist  601  Bold 
Swiss  721  Bold  Outline 
Brush  451  Brush  Script 
Aldine  851  FTC  Garamond  Light 

Aldine  851  ITC  Garamond  Book  Condensed 
Aldine  851  ITC  Garamond  Bold  Condensed 
Pi  Font  2 
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ADOBp  FONT  METRIC  FILES 

Specification 

Version  2.0 


POSTSCRIPT 


January  16. 1989 

PostScripj®  Developer  Tools  6  Strategies  Group 


Adobe  Systems  inoorporeled 
1685  Cha^SNi  Roed  PO  Boi  7900 
Mountain  View,  CA  94039.7900 
(415)96t-M00 
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C<vyri|lrt  6 1919, 1911, 1917  by  Adobe  Syiopu  locoipanud 

AO  rilfcx  n$trf*d.  No  pM  at  ihii  piiblicuiai  any  be  lepwAioed.  pend  m  •  mricrtl  typan,  or 

*MM«med,  ■  illy /oioi  or  by  ioy  ■tioi,  ebeuwik,  oweKMiieel,  pborocopyioi.  lecordim.  or  orlier- 

vile,  wiihouilhe  prior  wriBco  pOTMiiiao  ol  (be  pobluher. 

PonSaipi  lod  Addbc  ere  ie|Meied  mdoouiki  of  aod  dte  taiScripi  tofo  ii  •  ndeaaik  ol 
Adobe  Syneou  looerpoiaied 

Ibe  infocmatioB  beicia  ii  ftiniffacd  for  infoiiBatMml  uie  only,  it  wbjeca  lo  rAangc  vtiboa  oaioe, 
M>d  ihouid  nor  be  ooniuued  m  •  oommumcM  by  Adobe  Syncmi  Inoorponied.  Adobe  Synou 
leearpoceud  eiiumci  do  luponiibiliiy  or  liibiliiy  lot  any  enon  or  naccuiKici  ibu  OMy  * 
dtii  Ibc  roAvaie  deicnbed  in  lUr  book  ii  fumihad  under  lioemc  end  aey  only  be  used  or 
eopied  in  iceordenoe  with  the  tcmi  of  raeb  beente. 
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ADOBE  FONT  METRIC  FILES 
Specification 
Version  2.0 

POSTSCRIPT 

January  16.  1989 

PostScrpl^  Developer  Tools  and  Strategies  Group 


1.  INTRODUCTION 

This  document  describes  a  standard  interchange  fonnat  for  communicating  font 
metric  information  to  people  and  piognuns.  The  fonnat  is  ASCII  encoded  (for  both 
human  and  machine  readability),  machine  independent,  and  extensible.  Files  in  this 
formal  are  known  as  Adobe®  ^nt  Metrics  (AFM)  files  and  are  available  for  all  of 
Adobe  Sysiems's  PostScript  fonts. 


2.  PARSING  DETAILS 

gfh  AFM  file  contains  the  information  for  one  PostScript  printer  font  The  file 
begins  with  global  information  pertaining  to  the  font  as  a  whole,  followed  by 
sections  with  character  metrics,  kming  data  (optional)  and  composiie  character  data 
(optional).  The  file  format  is  line-oriented,  each  line  beginning  with  a  property 
Otey)  name,  followed  by  the  values  for  that  property.  Keys  and  values  are  separated 
by  one  or  more  white  space  characters  (space  or  tab). 

The  fomut  is; 


Key  value  value ... 

Key  names  are  case-sensitive.  All  keys  beginning  with  a  capital  letter  are  reserved 

for  use  by  Adobe  Systems;  user-defined  non-standard  entries  should  begin  with  a 

lowercase  letter.  The  Adobe  Systems  standard  keys  ate  detailed  below,  but  other 

keys  are  allowed  and  should  be  ignored  by  programs  not  recognizing  them. 

Values  will  be  one  of  the  following;  atrbg,  name,  number.  Integer  or  boolean. 

•  Strings  are  termiruued  by  the  end  of  line. 

•  Names  are  similar  to  ttings  except  that  they  may  not  contain  any  white  space 
characters;  they  are  terminated  by  white  space  characten  or  by  a  special 
termination  character  (see  section  on  “Character  Metrics’*  below). 

•  Numbers,  integers  and  booleans  ate  separated  by  white  tpaoc  characters,  which 
may  be  space,  newline,  or  tab. 

•  A  number  can  be  either  a  teal  number  or  an  integer,  and  both  must  be  allowed  for. 

•  A  boolean  is  either  the  value  true  or  false. 
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2.1  COMMENTS 

Commenis  may  be  present  in  a  font  metric  liie.  They  are  introduced  by  the  keyword 
Comment,  and  are  teminated  by  the  end  of  line.  Lines  should  be  no  longer  than  2SS 
characters  under  any  circumstances. 

Comment  string 

Hie  text  is  arbitrary,  and  should  be  ignored. 


3.  FILE  STRUCTURE 

An  AFM  file  has  several  sections,  exh  of  which  is  delimited  by  a  Start  and  End 
keyword.  The  main  section  contains  a  Pleader”  of  global  ftmt  information,  and  each 
of  the  other  sections  of  the  file  is  hierarchically  one  level  down  from  the  main 
section. 

StartFontMetrIcs  version 
EndFontMetrics 

These  comments  delimit  the  entire  font  metrics  file.  The  StartFontMetrics  line 
should  be  the  first  line  in  the  file,  and  the  EndFontMetrics  keyword  should  be  the 
last  line  in  the  file. 


3.1  GLOBAL  FONT  INFORMATION 

The  following  global  font  keys  are  the  same  as  those  in  the  top  level  or  Fontlnfo 
subdictionary  of  an  Adobe  Systems  PoftScript  font  dictionary.  Their  meanings  are 
described  in  the  chapter  on  fonts  in  the  PostScript  Language  Reference  Manual. 
Please  note  that  allhough  some  of  the  keys  in  the  PostScript  Fontlnfo 
subdictionary  begin  with  a  lowercase  letter  (e.g..  bFixedPitch,  version)  all  keys 
listed  here  begin  with  uppercase  leoen  to  distinguish  them  as  keys  reserved  for  use 
by  Adobe  Systems.  All  numeric  values  are  in  the  character  coordinate  system  (1000 
units  per  em). 

FontName  string 

Name  of  the  font  as  presented  to  the  PostScr^  findfont  operator. 

Example:  Garamond-Ught 

FullName  siring 

The  full  text  name  of  the  fonL  Example:  TTC  Garamond  Light 

FamilyName  string 

The  name  of  the  “font  funily”  to  which  the  fora  belongs. 

Example:  ITC  Garamond. 

Weight  string 

Weight  of  the  font  Example:  Roman,  Bold.  Light,  etc. 
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ItalicAngle  number 

Angle  (in  degrees  counter-clockwise  from  the  vertical)  of  the  dominant  vertical 
strokes  of  the  fom. 

Example:  *12. 


IsRxedPitch  boolean 

If  boolean  is  true,  this  indicates  that  the  font  is  a  fixed  pilch  (monoqiaced)  font.  A 
value  of  false  indicates  a  proportionally  qraced  font 

FontBBox  tlx  lly  urx  ury 

Four  mimbers  giving  the  lower  left  comer  and  the  upper  right  coiner  of  the  font 
bounding  box.  Note:  the  bounding  box  given  here  is  t^t  of  the  flattened  paths,  not 
the  Bezier  curve  descriptions.  These  values  are  all  integers,  and  should  be  rounded 
off  if  necessary. 

UnderllnePosItion  number 

Distance  from  the  baseline  for  centering  underlining  strokes. 


UnderllneThickness  number 

This  is  the  stroke  width  for  underlining,  expressed  in  character  coordinate 
(proportional  to  the  font  characters).  It  ^ould  be  adjusted  for  point  size  by  any 
application  wishing  to  perform  underlining. 


Version  string 

Font  version  identifier.  Matches  the  string  found  in  the  Fbntlnfo  dictionary  of  the 
font  itself. 

Notice  string 

Font  name  trademark  or  copyright  notice. 


EncodIngSeheme  string 

String  indicating  the  default  encoding  vector  for  this  font  The  most  common  one  is 
AdobeStandardEneoding.  Special  foms  may  simply  suie  FontSpecifxc. 

CapHelght  number 

Top  of  capital  H,  measured  in  character  coordinate  system. 


XHelght  number 

Top  of  lower  case  x,  measured  in  character  coordinates. 

Ascender  number 

Top  of  lower  case  d. 

Descender  number 

Bottom  of  lower  case  p. 
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4.  INDIVIDUAL  CHARACTER  METRICS 


Each  character’s  metrics  consists  of  a  list  of  keys  and  values  separated  by 
semicolons;  the  metrics  for  a  given  character  will  always  be  contained  in  one  line. 
The  characters  are  sorted  by  n»unerically  ascending  character  code.  Unencoded 
charvten  follow  the  encoded  charactenand  are  identified  by  character  codes  of  *1. 

Example:  A  character  metric  data  line  mi^i  look  like  thiK 

C102;WX333;Nf;B21  0  382  685;  L 1  fi;  L I  fl; 

StartCharMetrics  integer 
EndCharMetrlcs 

Ihese  comments  introduce  (and  conclude)  the  character  metrics  section  of  the  file. 
The  integer  value  indicates  how  many  individual  characten  to  expect 


C  integer 

Decimal  value  of  default  PostScript  character  code  (•!  if  unencoded). 

WX  number 

Character  width  in  X  (y  is  0). 

W  number number y 

Character  width  vector  (x^i 

N  name 

PostScript  character  name. 

B  I  lx  lly  urx  ury 

Character  bounding  box  where  tlx.  lly,  urx,  and  ury  are  all  numbers. 


L  successor  ligature 

Ligature  sequence  where  successor  and  ligature  ate  both  names.  The  current  character 
may  join  with  the  character  named  successor  to  form  the  character  named  ligature. 
Note  that  characten  may  have  more  than  one  such  entry.  (See  example  above.) 


5.  KERNING  DATA 

The  kerning  dau  section  is  opdonal;  it  may  or  may  not  be  present  for  a  given  font 
The  section  is  surrounded  by  the  lines  StartKcmData  and  EndKcmData.  Kerning 
data  is  supplied  in  two  forms:  Back  kerning  and  peir>wise  kerning.  IVack  kerning  is 
applied  to  all  characten  uniformly  whereas  pair*wise  kerning  is  apidied  to  specific 
character  pain.  Tnck  kerning  and  pair>wise  kerning  may  be  used  independently  or 
together  (Le.,  it  is  possible  to  apply  sack  kerning  to  a  line  of  text  and  then  to 
apply  pair-wise  kerning  on  top  of  that).  The  two  forms  of  kerning  data  are  treated 
as  subsections  wiCiin  the  kerning  data  section  and  both  sections  need  not  be  presenL 
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StartKemData 

EndKernData 

Utese  comments  miroduce  (and  conclude)  the  keming  section  of  the  file. 


5.1  TRACK  KERNING 

Ihe  tnck  keming  diu  is  surrounded  by  the  lines: 


StartTrackKern  integer 
EndTrackKern 

Where  iiueger  indicates  bow  many  diflerent  sets  of  track  keming  dau  are  present 

Normally  track  keming  is  provided  in  different  degrees  of  tightness.  Within  a  track 
(a  degree  of  dghuiess),  the  amount  to  decrease  (or  possibly  increase)  the  amount  of 
space  between  characters  increases  (or  possibly  decreases)  with  the  point  size  of  the 
font  (e.g..  for  tight  track  keming.  the  amount  to  decrease  the  space  between 
characters  at  6  point  might  be  0.1  points  and  at  72  poim  it  might  be  3.78  points). 

Ibe  dau  itself  begins  with  the  key  TracfcKem  and  is  followed  by  the  track  keming 
information: 


TrackKom  degree  min-p^e  min-kem  max-ptslze  max-kem 

Ibe  degree  is  an  integer  where  increasingly  negative  degrees  represem  tighter  track 
keming  and  increasingly  positive  degrees  represent  looser  track  keming.  min-pt-site, 
nuH-ken-emt,  max-pt^sise  and  max-kem-am  ate  all  numbers.  Since  the  track 
keming  is  a  linear  function,  the  minimum  and  maumum  cut-off  values  (point  sizes) 
are  provided  along  with  the  amount  to  track  kem  by  at  the  poim  size.  The  keming 
amounts  are  given  relative  Ur  the  point  size.  From  those  4  values,  the  track  keming 
functitm  can  be  derived.  Ibe  tnck  keming  function  is  a  linear  function.  Ibe  equation 
for  the  line  can  be  determined  from  the  dau  provided  and,  therefore,  the  track 
keming  values  for  any  point  size  can  be  determined.  The  track  keming  values  for  any 
point  size  below/above  the  minimumAnaximum  point  size  are  constant  (the 
minimum  keming  arturuni/tnaximum  keming  amount). 

In  general  the  track  keming  function  is  as  foltows: 

TrackKcm  degree  pg  kg  pj  kj 

Where  z  ■  current  point  size 
Where  kj  ■  max-kem-amt,  kg  ■  min>kem-amt 
Wberepj  ■  inax-pi-size,p^  ■  min-pt>size 

Ax)-  kg 

J(X)m  {kj.kg)»X*(kg*Pj^kj*pO) 

Ax)-*j 


forx  <  pg 

toepg  ix  i  pj 

toix>pj 
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See  the  last  section  of  this  document  for  a  good  example  of  these  ke)'«'onls  in  use. 
Below  is  a  sample  of  text  printed  using  the»  ttack  keining  values. 

Figure  1:  Track  Kerning 


12  pt- 


An  illustmtion  of  how  track  keniing  works. 
An  illustration  of  how  track  kerning  works. 
-  -  I  An  illustration  of  how  track  keining  works. 

An  iUusoadonofhow  trade  keining  worics. 


■  18 pt  ■  "■  -  '■  "  ■  . 

An  illustration  of  how  track  kerning  works. 
An  illustration  of  how  track  kerning  works. 
An  illustration  of  how  track  kerning  works. 

An  illustration  ofhow  track  kerning  works. 
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5.2  PAIR-WISE  KERNING 


Hie  pair-wise  kerning  data  is  surrounded  by  the  lines: 


StartKemPaIrs  integer 
EndKernPaIrs 

Where  bueger  indicates  how  many  pairs  to  expect 

There  will  be  one  kerning  pair  per  line.  Each  line  will  begin  with  a  keyword  of  the 
IbnnKPorKPX. 


KP  name  j  name 2  number^  number y 

Name  of  the  fust  character  in  the  kerning  pair  followed  by  the  name  of  the  second 
chanctv  followed  by  the  kerning  vector  specified  as  an  (x.y)  pair.  The  kerning 
vector  is  the  amount  to  move  the  second  character  by  relative  to  the  first  character 
to  position  it  properly.  The  kerning  vector  is  specified  in  the  character  roorHinat^ 
system.  In  order  to  use  this  vector  it  is  necessary  to  transform  it  into  user  space  and 
a^e  it  by  the  point  size  in  use.  The  best  way  to  do  this  is  to  use  the  FontMatrix 
entry  in  the  current  fom  dictionary. 


KPX  name^  name 2  number 

Name  of  the  first  character  in  the  kerning  pair  followed  by  the  name  of  the  second 
character  followed  by  the  kerning  amount  in  the  x  direction  (y  is  zero).  The  kerning 
amoum  is  specified  in  the  uniu  of  the  ehiractfr  Bnnntinai«»  system. 


A  character  pair  kerning  line  might  look  like  this: 


KPX  V  A -129 

Below  is  an  example  of  pair-wise  kerning  applied  to  100  point  characters: 


Rgure  2:  Palr-wlse  kerning 


VA  Yh 

-t2.9 

Characters  printed  without  kerning  Pair-wise  kerning  applied 
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6.  COMPOSITE  CHARACTER  DATA 

ITie  composite  character  data  section  is  also  optional.  Composite  characters  are  new 
characters  that  are  made  tip  of  characters  already  existing  in  the  font,  such  as 
accented  characters.  Character  metric  information  for  composite  characters  is  found 
in  the  Metrics  Kction  of  the  AFM  file.  Although  most  PostSci^  fonts 

available  from  Adobe  Systems  include  a  rather  extensive  mt  of  composite  characters, 
some  applications  may  wish  to  generate  their  own.  This  section  provides  the  data 
necessary  for  accurate  positioning  of  the  individual  pieces.  All  units  ate  expressed  in 
the  1000  unii-per*«m  chmter  coordinate  system. 


StartComposItas  Integer 
EndComposItes 

Where  frneger  indicates  how  many  pairs  to  expect. 

The  data  for  each  composite  character  is  represented  as  a  list  of  keys  and  values 
separated  by  semicolons.  Each  composite  ch^ter  gets  one  line  of  description.  The 
nandard  keys  ate: 


CC  name  Integer 

The  composite  character  name  followed  by  the  number  of  paru  that  make  up  the 
composite. 


PCC  name  deltax  deltay 

One  of  the  pans  of  the  composite  character.  The  character  name  is  given  followed  by 
the  X  and  y  displaoement  from  the  origin. 

A  composite  character  line  might  look  like  this: 


CC  Aacute  2:  PCC  A  0  0;  PCC  acute  194  214; 


Figure  3:  Example  of  positioning  for  a  composite  charactef 


Positioning  of 
character  A 


Positioning  of  Composite  Aacute 

character  acute 
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7.  EXAMPLE  FILE 


Hie  fotlowing  is  an  example  of  an  AFM  file  for  Times  Roman,  although  some  of 
the  data  have  been  omitted  to  keep  it  sborL 


StartFontMetrics  2.0 

Comment  Copyright  (c)  1964  Adobe  Systems  incorporated. 
Comment  All  Rights  Reserved. 

FbntName  Times-Roman 
FullName  Times  Roman 
FamUyName  Times 
Weight  Medium 
RalicAngle  0.6 
isFixedPitch  false 
UnderiinePosition  *98 
UnderlineThicKness  54 
Version  001.000 

Notice  Times  is  a  trademark  of  Allied  Corporation. 

EnoodingSchema  AdobeSlandardEncoding 

FbntBBox  -167  *252  1004  904 

CapHeight  673 

XHeight44S 

Descender  *219 

Ascender  686 

StartCharMetrics  210 

C32;WX250;N8paca:BQOOO: 

C  33  :  WX  333  :  N  exdam ;  B 128  -17  240  673  ; 

C34  ;  WX 408  : N quotedbl : B  46 445 313  685 ; 

C  35 :  WX  500  :  N  numbersign  ;  B  20  -17  481  673  ; 

C  36 :  WX  500 ;  N  dollar ;  B  45  -92  456  726 ; 

C  37 :  WX  833  ;  N  percent ;  B  63  -36  771  655  ; 

...  -  Unes  omitted  ior  brevity  ~ 

C101  ;  WX 444  ;Ne;B24 -17416469; 
Cl02;WX333;Nf:B21  0  382  685  ;Lifi  :Llfl ; 

C 103  :  WX  500 ;  N  g  ;  B  24  -220  469  468 ; 
Cl04:WX500:Nh;B1l0  487  686; 

C 1 05 ;  WX  278 ;  N I ;  B  25  0  255  685 : 

C 106 ;  WX  278 :  N  J ;  B -56 -217  205  685 : 

C 107 ;  WX500  ;N  k ;  B7  0  496  666 ; 

...-llnesomittedtorbrevity- 

C  248  :  WX  278 ;  N  Islash  ;  B  0  0  283  685  : 

C  249 ;  WX  500 ;  N  oslash  ;  B  30  -1 04  469  566 : 
C250;WX722:Noe:B30-10684  462; 

C251  :WX500:Noermandbls;Bl3  0  468  686; 

C -1  ;  WX  722  ; N  Aacute ; B22  0  702 873 ; 

C-1  ;WX722:NAdrcumflex:B22  0  702  875; 

C-1  ;WX722:NAdleresis;B22  0  702  819: 

...  -  lines  omitted  lOr  brevity  - 
EndCharMetrics 
StartKemOata 
SlartTrackKern  3 
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Comment  Light  kerning 
TrackKem-1  14  0  72*1.89 
Comment  Medium  kerning 
TrackKern  *2  8  0  72  *3.2 
Comment  Tight  kerning 
TrackKern  *3  6 -.1  72*3.78 
EndTrackKem 
StartKemPairs  2 
KPXVA-129 
KPXAY-92 
EndKemPairs 
EndKemOata 
StartComposites  1 

CC  Aacute  2;  PCC  A  0  0;  PCC  acute  194  214 

EndComposites 

EndFontMelrics 
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APPENDIX  C 

REGISTRATION  PROPOSALS 
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PART  1 

PROPOSALS  APPROVED  BY  X3H3  IN  SEPTEMBER  1989 
IN  LETTER  BALLOT  #80.  PINAL  TEXT  READY  TO 
FORWARD  TO  ISO  IS  INCLUDED. 
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Prssentatlon  data  of 


l.iM.M-tTBI 


10  Aoril  1987 


SDonsorln 


Class  of  Graohleal  Item:  I  UNETYPE 


Name:  usar-soecified  dash  oattern 


Oaserlptlon 


This  usar-specifiad  dash  pattam  linatype  consists  of  altornating  dashss  and  spaces.  By  using  tha  ragistarad 
ascapa  function  Sat  Dash,  a  usar  can  axarcisa  praciss  control  ovar  important  aspacts  of  tha  appaaranca  of  linas  of 
this  typa.  This  control  indudas  tha  ability  to  salact  the  length  of  each  dash  and  of  each  space,  tha  offset  to  tha 
start  of  tha  *dash  pattern*,  and  whether  tha  dash  pattern  is  restarted  at  each  portion  of  a  primit'  j.  In  addition, 
line  cap,  line  join,  and  mitre  limit — each  of  which  can  be  sat  by  a  registered  escape  function — apply  to  primitives  of 
this  linatype. 


_ _ _  Additional  Comments 


This  registration  proposal  is  accompanied  by  a  proposal  to  register  an  escape  function  •  Set  Dash  •  that  defines  the 
currant  user-specified  dash  pattern.  It  is  intended  th-^‘  these  proposals  be  processed  together. 

This  iinetype  is  not  intended  to  be  used  as  an  edgetype. 


_ _ Justification  for  Inclusion 


User  specified  linetypas  are  needed  to  support  the  requirements  of  office  document  exchange  and  publishing.  They 
are  commonly  found  in  widely  available  proprietary  graphics  systems. 


Relationship  to  Standards 


1)  ISO  7942  (GKS)  -  Specifies  a  registered  linatype  to  supplement  those  defined  in  5.4.1. 

2)  ISO  8632  (CGM)  -  Specifies  a  registered  linatype  to  supplement  those  defined  in  S.7.C. 

3)  ANSI  Y14.2M-1979  -  Lina  Conventions  and  Lettering. 
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Proposal  NumberTfse 


Data  of  Prasantatton:  I  10  April  1987 


IBZEQISEn 


Authority:  I  ANSI 


Class  of  Graphical  Item:  I  ESCAPE 


Specific  Escape  I  Function  Identifier:  |  Sat  Oash 


Description 


This  escape  function  sets  the  characteristics  of  the  user-specified  (registered)  linelype.  Such  a  user-specified 
dash  pattern  linetypa  consists  of  alternating  dashes  and  spaces.  This  escape  function  allows  a  user  to  exercise 
precise  control  over  important  aspects  of  the  appearance  of  lines  of  this  type.  This  control  includes  the  ability  to 
select  the  length  of  each  dash  and  of  each  space,  the  offset  to  the  start  of  the  *dash  pattern*,  and  whether  the 
dash  pattern  is  restarted  at  each  portion  of  a  primitive,  in  addition,  line  cap,  line  join,  and  mitre  limit— each  of 
which  can  be  set  by  a  registered  escape  function — apply  to  primitives  of  this  linetype.  See  attached  sheet  for 
additional  details. 


Additional  Comments 


Justification  for  inclusion 


User  specified  line  types  are  commonly  found  in  proprietary  graphics  systems.  They  are  needed  to  support  the 
requirements  of  office  document  exchange  and  publishing. 


Relationship  to  Standards 


1)  ISO  7942  (GKS)  -  Specifies  a  registered  escape  as  defined  in  5.2. 

2)  ISO  8632  (CGM)  •  Specifies  a  registered  escape  as  defined  in  5.8.1. 

3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  escape. 
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Set  Dash 


Deaeript^ion: 

Set  Daah  controls  the  dash  pattern  used  with  line  primitives  of 
registered  linetype  "user-specified  dash  pattern"  (linetype  TBD) . 
If  the  array  of  dash  pattern  lengths  is  empty  (i.e,  the  number  of 
lengths  is  zero),  the  linetype  is  equivalent  to  solid.  This  is  the 
default  value.  If  the  array  of  dash  pattern  lengths  is  not  empty, 
line  primitives  of  registered  linetype  "user-specified  dash 
pattern"  are  drawn  with  dashes  whose  pattern  is  defined  by  the 
array  of  lengths . 

Each  length  in  the  array  of  dash  pattern  lengths  must  be 
non-negative.  If  any  length  in  the  dash  pattern  length  array  is 
negative,  a  length  of  zero  shall  be  substituted.  At  least  one 
length  in  the  array  must  be  non-zero.  If  all  lengths  are  zero,  the 
linetype  is  equivalent  to  solid,  if  the  number  of  lengths  is  less 
than  zero,  a  value  of  zero  shall  be  substituted. 

The  elements  of  the  array  of  dash  pattern  lengths  are  interpreted 
in  sequence  as  relative  distances  along  the  primitive.  These 
distances  alternately  specify  the  length  of  a  gap  between  dashes . 
The  contents  of  the  array  are  used  cyclically,  that  is  when  the  end 
of  the  array  is  reached,  the  pattern  starts  over  at  the  beginning. 

Dashed  lines  wrap  around  curves  and  corners  just  as  solid  lines  do. 
The  ends  of  each  dash  receive  no  special  treatments .  In  particular, 
the  "ends"  of  dashes  are  not  treated  with  current  line  cap.  No 
measures  other  than  continuity  as  described  below,  are  provided  to 
coordinate  the  dash  pattern  with  features  of  an  output  primitive. 

The  offset  value  may  be  thought  of  as  the  "phase"  of  the  dash 
pattern  relative  to  the  start  of  the  path.  It  is  interpreted  as  a 
distance  into  the  dash  pattern  at  which  the  pattern  should  be 
started.  Before  beginning  output  of  the  dash  pattern,  the  elements 
of  the  array  of  dash  pattern  lengths  are  cycled  through,  and  the 
distances  of  alternating  dashes  and  gaps  added  up,  but  without 
generating  any  output.  When  the  offset  distance  into  dash  pattern 
has  been  reached,  the  primitive  is  drawn  (from  its  beginning)  using 
the  dash  pattern  from  the  point  that  has  been  reached.  If  the 
offset  is  greater  than  the  total  length  (the  sum  of  all  lengths  in 
the  dash  pattern  length  array) ,  the  lengths  in  the  array  shall  be 
re-cycled  from  the  beginning.  This  process  shall  be  repeated  as 
many  times  as  necessary  until  the  offset  distance  is  reached. 

When  continuity  is  set  to  restart,  each  portion  of  a  primitive 
(e.g.  each  line  segment  within  a  polyline)  is  treated 
independently;  i.e.  the  dash  pattern  is  restarted  (and  offset 
applied)  at  the  beginning  of  each  portion.  When  continuity  is  set 
to  continuous,  the  dash  pattern  is  not  restarted  in  going  from  one 
portion  of  a  primitive  to  the  next.  If  continuity  is  not  either 
restart  or  continuous,  the  default  value  of  restart  shall  be  used. 
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Relationship  to.  .particular  _ atandarda ; 

1)  CGM  Functional  Specification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

The  elements  of  the  array  of  dash  pattern  lengths  are  interpreted 
in  sequence  as  distances  in  VDC  units  along  the  primitive.  The 
offset  value  is  in  VDC  units.  A  functional  description  of  the  Set 
Dash  escape  parameters  is: 

Parameters ; 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 


data  record  (D) : 
offset  (VDC) 

continuity  (one  of:  restart,  continuous)  (E) 
list  of  lengths  (nVDC) 
dash  pattern  lengths  array 

Items  for  Data  Record: 

offset 

continuity 

number  of  lengths 

dash  pattern  lengths  array 

Data  Record  Description: 

The  parameters  define  the  offset,  continuity,  number  of  dash 
pattern  lengths,  and  the  dash  pattern  lengths. 
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2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items), 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 


3)  GKS  Functional  Specification  (reference  ISO  7942  GKS 
Functional  Description) 

The  set  dash  escape  is  applicable  at  GKS  level  Oa  and  above.  A 
functional  description  of  its  parameters  is  given  below: 


Name  Values  Data  Type  Range 

escape  function  identifier  as  assigned  N 

input  data  record: 

offset  WC 

continuity  (RESTART,  CONTINOOUS) 
number  of  lengths 
dash  pattern  lengths 
array  WC 

output  data  record: 
none 

Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  in  one  of  the 
states  GKOPfWSOP,  WSAC,  or  SGOP 


R 

E 

I  >-l 

nxR 
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4)  frKS  rORTBAN  language  binding  (reference  ISO/IEC  8651-1^ 

GKS  Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  sxibclause  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (CONT,  DIMLEN,  OFFSET,  LEN) 


Input  Parameters ; 

INTEGER  CONT 
INTEGER  DIMLEN 

REAL  OFFSET 
REAL  LEN (DIMLEN) 

Output  Parameters : 

NONE 


continuity  (RESTART,  CONTINUOUS) 
dimension  of  the  dash  pattern  lengths 
array 

offset  into  dash  pattern 
dash  pattern  lengths  array 


The  following  mnemonic  FORTRAN  names  and  their  values  for  GKS 
ENUMERATION  type  values  are  added  to  the  list  in  the  GKS 
FORTRAN  binding; 

continuity  indicator  restart,  continuous 

INTEGER  GREST,  GCONT 

PARAMETER  (GREST-0,  GCONT- 1) 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  subclause  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Parameters  used  by  the  Pack  Data  Record  function  for  the  Input  Data 
Record: 

INTEGER  IL 
INTEGER  IA(  1  ) 

INTEGER  IA(  2  ) 

INTEGER  RL 
REAL  RA(  1  ) 

REAL  RA(  2  ) 

REAL  RA(  3  ) 

REAL  RA(1  +  number  of  dash  pattern  lengths) 

last  length 

INTEGER  SL  0 


2 

continuity  (RESTART,  CONTINUOUS) 
number  of  dash  pattern  lengths 
1+  number  of  dash  pattern  lengths 
offset 

first  length 
second  length 


The  Unpack  Data  Record  function  is  not  required  by  this  escape. 
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5)  Pascal  language  binding  (reference:  ISO/IEC  8651-2,  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  Is  proposed  for  the  procedure 
"GEscape"  as  defined  In  subclause  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


GEscapeContinuity  -  (GVEscapeRestart,  GVEscapeContinuous) ; 

GREscapeDataIn  -  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 
1:  ( 

DOOOl  Offset  :  REAL 

UOOOl  Continuity  :  GEscapeContinuity; 

OOOOl  N^l^^berLengths  :  INTEGER; 

UOOOl  Lengths  :  REAL  ) ; 

END; 

GREscapeDataOut  *  RECORD 

CASE  EscapelD  :  GTEscapeDataTag  of 

l5  ()  ;  (*Null  Record*) 

END; 
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6)  6KS  Ada  language  binding  (reference  ISO/IEC  8651-3  GKS 
Language  Bindings;  Part  3:  Ada) 

Registered  ESCAPE'S  are  in  a  library  package  named  GKS^ESCAPE.  GKS 
Ada  provides  a  data  type  package,  GKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SETJDASH"  form  (as  defined  in 
subclause  4 . 1  of  the  GKS  Ada  Icuiguage  binding)  of  the  ESCAPE  is : 


— Escape  function  for  a  user  specified  dash  pattern. 

— Data  types  ESCAPE  ID  and  ESCAPE^FLOAT  are  defined  in  package 
— GKS_ESCAPE .  ” 

— Other  data  types  are  defined  in  package  GKS_TYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package  GKS  ESCAPE  is 

type  OFFSET  is  ESCAPE_FLOAT; 

type  CONTINUITY  CHOICE  is  (RESTART, CONTINUOUS) ; 
type  DASH  PATTERN  LENGTHS_ARRAY  is  array 

(SMALL  NATURAL  range  <»of  ESCAPE  FLOAT: 
type  SET__DASH__DATA_RECORD  (NUMBER_OF_LENGTHS :  SMALL_NATURAL :  -  ( )  )  is 
record”  ”  ”  ” 

OFFSET  tin  ESCAPE  FLOAT; 

CONTINUITY  tin  CONTINUITY_CHOICE: 

DASH__PATTERN__LENGTHS  :in  DASH_PATTERN_LENGTH  ARRAY 

(1 .  .  number_of_lengthsT; 

end  record; 


procedure  SET  DASH {DASH_RECORD  tin  SET  DASH  DATA  RECORD); 


— more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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Sponsoring  Authority!  I  ANSI 


Class  ot  Graphical  Item;  I ESCAP^ 


Specific  Escape  I  Function  Identifier;  |  Sat  Line  Cap 


Description 


This  escape  function  sets  a  value  for  the  currant  line  cap.  This  value  determines  the  shape  put  at  the  ends  of  line 
segments.  The  shape  is  not  applied  to  the  ends  of  individual  ‘dashes*  that  compose  some  linetypas.  Sea  attached 
sheet  for  additional  details. 


Additional  Comments 


None. 


Justification  for  Inclusion 


User  specified  line  caps  are  commonly  found  in  proprietary  graphics  systems.  They  are  needed  to  support  the 
requirements  of  office  document  exchange  and  publishing. 


Relationship  to  Standards 


1)  ISO  7942  (GKS)  -  Specifies  a  registered  escape  as  defined  in  5.2. 


2)  ISO  8632  (CGM)  -  Specifies  a  registered  escape  as  defined  in  5.8.1. 

3)  ISO  8651  (GKS  Language  Bindings)  -  Specifies  a  registered  escape. 


Set  Line  Cap 


Paaeripfeion: 

Set  Cap  selects  the  line  cap  value  specified  by  the  line  cap 

indicator.  This  value  determines  the  shape  to  be  put  at  the  ends  of 
line  segments.  The  shape  is  not  applied  to  the  ends  of  individual 
"dashes"  that  compose  some  linetypes.  The  following  line  cap  values 
are  defined  with  this  proposal: 

butt  cap  :  the  line  is  squared  off  at  the  endpoint;  there  is 
no  projection  beyond  the  endpoint. 

round  cap  :  a  semicircular  arc  with  diameter  equal  to  the 
line  width  is  drawn  around  the  endpoint  and  filled.  The 
drawn  line  thus  projects  beyond  the  endpoint . 

projecting  square  cap  :  the  line  is  squared  off  at  a 
distance  equal  to  half  the  line  width  beyond  the  endpoint . 

If  the  line  cap  value  is  not  one  of  the  defined  values,  the  default 
value,  butt  cap,  shall  be  used. 

Relationship  to.  particular _ ataOdarda ; 


1)  CGM  functional  Specification  (reference  ISO  8632  CGM; 

Part  1 :  Functional  Description) 

A  functional  description  of  the  Set  Line  Cap  escape  parameters  is : 
Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (0) : 

line  cap  indicator  (E) 


Items  for  Data  Record: 
line  cap  indicator 

The  following  line  cap  indicator  values  are  defined: 

1 :  butt  cap 
2 :  round  cap 

3:  projecting  square  cap 
Data  Record  Description: 

The  parameter  defines  the  line  cap  value. 
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2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sec[uential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 

3)  6KS  Functional  Specification  (reference  ISO  7942  GKS 
Functional  Description) 

This  escape  is  applicable  at  (SKS  level  Oa  and  above.  A  functional 
description  of  its  parameters  is  given  below: 

Kama  Values 

escape  function  identifier  as  assigned 

input  data  record: 

line  cap  indicate'  (BUTT,  ROUND, 

PROJECTING  SQUARE) 

output  data  record: 
none 

Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  in  one  of  the 
states  GKOP,MSOP,  WSAC,  or  SGOP 


Data  Type 
N 

E 


4)  GKS  FORTRAN  language  binding  (reference  ISO/IEC  8651-1,  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  subclause  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (LNCAP ) 

Input  Parameters : 

INTEGER  LNCAP  line  cap  indicator  (BUTT,  ROUND, 

PROJECTING  SQUARE) 

Output  Parameters : 

NONE 
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The  following  nmemonic  FORTRAN  names  and  their  values  for  GKS 
ENUMERATION  type  values  are  added  to  the  list  in  the  GKS 
FORTRAN  binding: 


line  cap  indicator 

INTEGER 

PARAMETER 


butt, 

GBUTT, 

(GBUTT»1, 


round,  projecting  square 

GROUND,  GPROSQ 

GROUND-2,  GPROSQ-3) 


b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  subclause  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Parameters  used  by  the  Pack  Data  Record  function  for  the  Input  Data 
Record: 

INTEGER  IL 
INTEGER  lA  (1) 

INTEGER  RL  0 
INTEGER  SL  0 

The  Unpack  Data  Record  function  is  not  required  by  this  escape. 


1 

line  cap  indicator  (BUTT,  ROUND, 
PROJECTING  SQUARE) 
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5)  Pascal  language  binding  (reference:  ISO/IEC  8651-2,  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GESCAPE"  as  defined  in  subclause  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


GEscapeLineEndType  -  (GVEscapeButt,  (^VEscapeRound, 

GVEscapePro jectingSquare) ; 


GREscapeDataIn  »  RECORD 

CASE  Escape ID  :  GTEscapeDataTag  of 
1:  ( 

UOOOl  Linecap  :  GEscapeLineEndType) ; 

End; 


GREscapeDataOut  RECORD 

CASE  Escape Id  :  GTEscapeDataTag  of 
1:  0  ;  (*Null  Record  *) 

END; 
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6)  6KS  Ada  language  binding  (reference  ISO/IEC  8651-3,  GKS 
Language  Bindings;  Part  3: Ada) 

Registered  ESCAPE’S  are  in  a  library  package  named  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  package,  GKSJTYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SET_LINE__CAP"  form  (as  defined  in 
subclause  4.1  of  the  GKS  Ada  language  binding)  of  the  ESCAPE  is : 


— Escape  function  for  a  set  line  cap. 

— Data  type  ESCAPE  ID  is  defined  in  package  GKS__ESCAPE. 
—Other  data  types  are  defined  in  package  GKSJTYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package"”GKS_ESCAPE  is 

type  LINE_CAP_INDICATOR_TYPE  is  (BUTT,  ROUND,  PROJECTING  SQUARE)  ; 
LINE_CAP_INDICATOR_VALUE  :in  LINE_CAP_INDICATOR_TYPE; 

procedure  SET_LINE  CAP 

(LINE  CAP  INDICATOR  VALUE  ;in  LINE  CAP  INDICATOR  TYPE) ; 


—more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 


172 


Date  of  Preaantatlon:  I  10  April  1987 


Sponsorina  Authortt 


Class  of  Graphical  item:  I  ESCAPE 


Specific  Escape  I  Function  Identifier:  t  Set  Line  Mitre  Limit 


Description 


This  escape  function  sets  the  line  mitre  limit  value.  This  value  helps  determine  the  shape  put  at  comers  between 
portions  of  lines  primitives.  Its  purpose  is  to  place  a  limit  on  how  long  a  'spike*  can  emanate  from  the  join  of 
two  portions  of  a  line  pn'mitive  by  truncating*  long  mitre  joins  into  bevel  joins.  See  attached  sheets  for 
additional  details. 


Additional  Comments 


_  Justification  for  Inclusion 


User  specifieo  mitre  limits  are  commonly  found  in  proprietary  graphics  systems.  They  are  needed  to  support  the 
requirements  of  office  document  exchange  and  publishing.  This  proposal  accompanies  proposal  39  for  a  Set  Line 
Join  escape  function. 


_  Relationship  to  Standards 


1 )  ISO  7942  (GKS)  -  Specifies  a  registered  escape  as  defined  in  5.2. 

2)  ISO  8632  (CGM)  •  Specifies  a  registered  escape  as  defined  in  5.8.1. 


3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  escape. 
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Dg3ei.ip-fciQn: 

Set  Lina  Mitre  Limit  sets  the  line  mitre  limit  value  used  in 
interpretation  of  line  primitives  to  mitre  length  specifier,  which 
must  be  a  number  greater  than  or  equal  to  1.  Mitre  limit  is  a 
dimensionless  number  that  controls  the  treatment  of  corners  between 
portions  of  line  primitives  when  mitre  joins  have  been  specified. 
related  registered  escape.  Set  Line  Join,  controls  the  type  of 
join  that  is  selected.  When  portions  connect  at  a  sharp  angle,  a 
mitre  join  results  in  a  spike  that  extends  well  beyond  the 
connection  point .  The  purpose  of  the  mitre  limit  is  to  cut  off  such 
spikes  when  when  they  become  objectionably  long.  If  the  mitre 
length  specifier  is  less  than  or  equal  to  1,  the  default  value  of  1 
shall  be  used. 

At  any  given  corner,  the  mitre  length  is  the  distance  from  the 
point  at  which  the  inner  edges  of  the  line  portions  intersect  to 
the  point  in  which  the  outside  edges  of  the  portions  intersect 
(i.e.,  the  diagonal  length  of  the  mitre).  This  distance  increases 
as  the  angle  between  the  portions  decreases.  Whenever  the  ratio  of 
the  mitre  length  to  the  line  width  exceeds  the  line  mitre  limit 
parameter  and  is  also  greater  than  1.415,  a  bevel  is  introduced  at 
the  join  perpendicular  to  the  angle  bisector  and  at  the  mitre 
limit.  (Note  that  this  is  not,  in  general  equivalent  to  introducing 
a  bevel  join  when  this  limit  is  reached.  Introducing  such  a  join 
causes  discontinous  behaviour,  where  small  changes  in  the  angle 
between  the  segments  results  in  radically  different  appearances . ) 
Whenever  the  ratio  of  the  line  mitre  length  to  the  line  width 
exceeds  the  line  mitre  limit  parameter  'and  is  also  less  than  or 
equal  to  1.415  (that  is,  when  the  line  mitre  limit  parameter  is 
between  1  and  1.415  inclusive),  a  bevel  join  is  implemented  at  the 
mitre  limit. 

The  ratio  of  line  mitre  length  to  line  width  is  directly  related  to 
the  angle  ^  between  the  segments  by  the  formula: 

mitre  length  /  line  width  -  1  /  sin  (^2) 

Examples  of  mitre  length  specifier  values  aru :  1.415  cuts  off 

mitres  (converts  them  to  bevels)  at  angles  less  than  90  degrees, 
2.0  cuts  off  mitres  at  angles  less  than  60  degrees,  and  10.0  cuts 
mitres  off  at  angles  less  than  11  degrees.  The  default  value  of 
line  mitre  limit  is  10.  Setting  the  line  mitre  limit  to  1  cuts  off 
mitres  at  all  angles  so  that  bevels  are  always  produced  even  when 
mitres  are  specified.  The  lengths  in  the  above  formula  must  be  in 
the  same  units  (WC,  VDC,  etc.)  and  cancel  out  to  yield  a 
dimensionless  mitre  length  specifier  value.  This  escape  applies  to 
line  primitives . 
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Reiationahip _ _ pax.ticTilag _ atandaxda : 

1)  CGM  Functional  Specification  (reference  ISO  8632  CGM; 

Part  1 :  Functional  Description) 

A  functional  description  of  the  Set  Line  Mitre  Limit  escape 
parameters  is : 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 

mitre  length  specifier (R) 

Items  for  Data  Record: 

mitre  length  specifier 

Data  Record  Description: 

The  parameter  defines  the  line  mitre  length  specifier  value. 

2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  6RS  Functional  Description  (reference  ISO  7  94  2  GKS 
functional  description) 

This  escape  is  applicable  at  level  Oa  and  above.  A  functional 
description  of  its  parameters  is  given  below: 

Name  Values  Data  Type 

escape  function  identifier  as  assigned  N 

input  data  record: 

mitre  length  specifier  R 

output  data  record: 
none 

Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  either  in  one  of  the 
states  GKOP,  WSOP,  WSAC,  or  SGOP 


4)  GKS  TORTRAM  language  binding  (reference  ISO/IEC  8651-1,  GKS 
Language  Bindings;  Part  1;  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  subclause  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (MITRE) 

Input  Parameters : 

REAL  MITRE  mitre  length 

Output  Parameters : 

NONE 
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b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 


Parameters  used  by  the  Pack  Data  Record  function  for  the  Input  Data 
Record: 


INTEGER  IL 
INTEGER  RL 
REAL  RA<  1  ) 
INTEGER  SL 


0 

1 

mitre  length 
0 


The  Unpack  Data  Record  function  is  not  required  by  this  escape. 

5)  Pascal  language  binding  (reference:  ISO/IEC  8651-2  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GESCAPE”  as  defined  in  subclause  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


GREscapeDataIn  -  Record 

CASE  EscapelD  :  GTEscapeOataTag  of 
1:  ( 

OOOOl  MitreLengthSpecif ier :  REAL  )/ 

END; 

GREscapeOataOut  -  RECORD 

CASE  Escapeld  :  GTEscapeOataTag  of 

1;  0  ;  (*Null  Record  *) 

END; 
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6)  GKS  Ada  languaga  binding  (reference  ISO/IEC  8651-3,  GKS 
Language  Bindings;  Part  3:  Ada) 

Registered  ESCAPE'S  are  in  a  library  package  named  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  package,  GKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SET__LINE_MITRE__LIMIT"  form  (as 
defined  in  subclause  4.1  of  the  GKS  Ada  language  binding)  of  the 
ESCAPE  is: 


— Escape  function  for  a  set  line  mitre  limit. 

— Data  types  ESCAPE_ID  and  ESCAPE_FLOAT  are  defined  in  package  GKS 
— GKS_ESCAPE . 

— Other  data  types  are  defined  in  package  GKS_TYPES. 


with  GKS  TYPES; 
use  GKS_TYPES; 
package  GKS  ESCAPE  is 

MITRE__i5nGTH_SPEC  IF  lER  :  in  ESCAP  E_FLOAT  ; 

procedure  SET  LINE_MITRE  LIMIT 

(MITRE  LIMIT  “  :in  MITRE_LENGTH ; 


— more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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Class  of  Graohleal  Item:  I  ESO'^S 
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Set  une  Join 


Description  _ 


This  escape  function  sets  a  line  join  value.  This  value  determines  the  shape  put  at  corners  between  portions  of 
line  primitives.  See  attached  sheet  for  additional  details. 


Additional  Comments 


Justification  for  Inclusion 


User  specified  line  joins  are  commonly  found  in  proprietary  graphics  systems.  They  are  needed  to  support  the 
requirements  of  office  document  exchange  and  publishing. 


Relationship  to  Standards 


1)  ISO  7942  (GKS)  '  Specifies  a  registered  escape  as  defined  in  5.2. 

2)  ISO  8632  (CGM)  -  Specifies  a  registered  escape  as  defined  in  5.8. 1. 


3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  escape. 


Set  Line  Join 


Paaeripfeion: 

Sat  Lina  Join  sets  the  current  line  join  value  to  line  join 
indicator.  This  establishes  the  shape  to  be  put  at  the  corners 
between  portions  (line  segments)  of  line  primitives-  The  following 
line  join  values  are  defined: 

aitra  join  :  the  outer  edge  of  the  two  portions  are  extended 
until  they  meet  at  a  point-  (Note  that  the  mitre  limit  value 
may  affect  the  appearance  of  these  joins  - ) 

rotxnd  join  :  a  circular  arc  with  diameter  equal  to  the  line 
width  is  drawn  around  the  vertex  between  the  adjoining 
segments  and  is  filled  in,  producing  a  rounded  corner - 

baval  join  ;  the  meeting  portions  are  finished  with  butt  end 
cap  and  the  resulting  tri2uigular  notch  is  filled  in- 

If  the  line  join  indicator  is  not  one  of  the  defined  values,  the 
default  value,  mitre  join,  shall  be  used. 

Join  styles  are  significant  only  at  points  where  consecutive 
portions  of  a  line  primitives  connect  at  an  angle;  portions  that 
meet  or  intersect  fortuitously  receive  no  special  treatment . 
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Relationship  to — particular _ gtandard-s  ; 

1)  C6M  runctional  Specification  (reference  ISO  8632  CGM; 

Part  1 ;  Functional  Description) 

A  functional  description  of  the  Set  Line  Join  escape  parameters  is : 
Parcuneters : 

function  identifier  (1)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 

line  join  indicator  (E) 


Items  for  Data  Record: 

line  join  indicator 

The  following  values  of  line  join  indicator  are  defined: 

1:  mitre  join 
2 :  round  join 
3:  bevel  join 

Data  Record  Description: 

The  parameter  defines  the  line  join  indicator  value. 

2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,2,  A) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  se<^ential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  6XS  Fuactional  Oaacription  (reference  ISO  7942  GKS 
functional  description) 

This  escape  is  applicable  at  level  Oa  and  above.  A  functional 
description  of  its  parameters  is  given  below: 

Marne  Values  Data  Type 

escape  function  identifier  as  assigned  N 

input  data  record:. 

line  join  indicator  (MITRE,  ROUND,  E 

BEVEL) 

output  data  record: 
none 


Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  in  one  of  the 
states  GKOPfWSOP,  nSAC,  or  SGOP 


4)  GKS  FORTRAM  language  binding  (reference  ISO/IEC  8651-1,  GKS 
Language  Bindings;  Part  1:  FORTRAN) 


a)  The  following  language  binding  is  proposed  for  the  "GEpqrs”  form 
(as  defined  in  subclause  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (LNJOIN> 


Input  Parameters ; 

INTEGER  LNJOIN  line  join  indicator  (MITRE,  ROUND, 

BEVEL) 

Output  Parameters : 

NONE 


The  following  mnemonic  FORTRAN  names  and  their  values  for  GKS 
ENUMERATION  type  values  are  added  to  the  list  in  the  GKS  FORTRAN 
binding: 


line  join 

INTEGER 

PARAMETER 


indicator 


mitre, 

GMITRE, 

(GMITRE-1, 


round, 
GROUND , 
GROUND-2, 


bevel 
GBEVEL 
GBEVEL-3 ) 
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b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  subclause  9..'  of  the  GKS 
FORTRAN  language  binding  standard: 

Parameters  used  by  the  Pack  Data  Record  function  for  the  Input  Data 
Record : 

INTEGER  IL  1 

INTEGER  1A(  1  )  line  join  indicator  (MITRE,  ROUND,  BEVEL) 
INTEGER  RL  0 
INTEGER  SL  0 

The  Unpack  Data  Record  function  is  not  required  by  this  escape. 


5)  Pascal  language  binding  (reference:  ISO/IEC  8651-2,  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GEscape”  as  defined  in  sxibclause  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


GEscapeLineJoin  -  (Mitre,  Round,  Bevel) / 


GREscapeDataIn  >■  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 
1:  ( 

UOOOl  LineJoinIndicator  :  GEscapeLineJoin) ; 

END; 


GREscapeDataOut  -  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 

1:  0  ;  (*Null  Record*) 

END; 
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6)  61CS  Ada  Languaga  binding  (reference  ISO/IEC  8651-3  GKS 
Language  Bindings;  Part  3:  Ada) 

Registered  ESCAPE'S  are  in  a  library  package  name  GKS__ESCAPE.  GKS 
Ada  provides  a  data  type  package,  GKSJTYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SET_LINE_J01N"  form  (as  defined  in 
subclause  4.1  of  the  GKS  Ada  language  binding)  of  the  ESCAPE  is : 


— Escape  function  for  a  set  line  join 

— Data  type  ESCAPE_ID  is  defined  in  package  GKS_ESCAPE. 
— Other  data  types  are  defined  in  package  GKS  TYPES. 


with  GKS  TYPES; 
use  GKS  TYPES; 
package“GKS  ESCAPES  is 

type  LINE  JOIN_INDICATOR_TYPE  is  (MITRE,  ROUND,  BEVEL) ; 
L1NE_JOIN”INDICATOR__VALOE  :  in  LINE_JOIN_INDICTOR__TYPE; 

procedure  SET  LINE  JOIN 

(LINE  "join  "indicator  VALUE  :  in  LINE  JOIN  INDICTOR  TYPE  ); 


— more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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i  Date  of  Presentation;  I  10  April  1987 

I  Sponsoring  Authority:  I  ANSI 

I  Class  of  Graphical  Item;  I  GCP 

I  GDP  Identitler;  I  Poly  Cubic  Bezier  Curw 


_ _ Daacrtptlon _ 

The  point  sot  used  with  this  GOP  is  divided  into  disjoint  sets  consisting  of  four  consecutivs  points  each.  A 
separate  Bezier  cubic  curve  is  drawn  using  each  consecutive  set  of  four  points.  The  curve  starts  at  the  first 
point  and  ends  at  the  fourth  point  within  each  sat  The  second  and  third  points  in  each  set  are  used  as  control 
points.  In  the  event  that  the  points  within  consecutive  sets  do  not  'overlap*  (for  example,  the  fourth  point  of  one 
set  does  not  have  the  same  value  as  the  first  point  in  the  next  set),  the  curve  segments  are  not  implicitly 
connected.  A  poly  Bezier  curve  is  a  line  primitive  that  takes  tine  attributes.  See  the  attached  sheets  tor  a 
detailed  description. 


Additional  Comments 

Nona 

• 

Justification  for  Incluston 

Bezier  curves  are  widely  available  in  proprietary  graphics  systems.  They  are  needed  to  support  the 
requirements  of  office  document  exchange  and  publishing. 


_ _ Relationship  to  Standards 

1 )  ISO  7942  (GKS)  •  Specifies  a  registered  GOP  as  defined  in  5.3. 


2)  ISO  8632  (CGM)  -  Specifies  a  registered  GOP  as  defined  in  5.6.10. 

3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  GOP.  (See  attached  sheets). 


Poly  Cubic  Bezier  Curve 


PoacriptionL 

Poly  Cubic  Bozior  Cuzv*  adds  a  Bezier  cubic  curve  between  the 
first  point,  referred  to  here  as  (Xg,  and  the  fourth  point  (Xj, 

Yj)  ,  using  (Xj,  Y^)  and  (X2fY2)  as  control  points,  for  each 
consecutive  set  of  four  points  in  the  point  list.  These  consecutive 
sets  of  points  are  obtained  by  dividing  the  point  list  into 
disjoint  sets  of  four  consecutive  points  each.  In  the  event  that 
points  within  the  consecutive  sets  do  not  "overlap"  (for  example, 
if  the  fourth  point  of  one  set  does  not  have  the  same  value  as  the 
first  point  of  the  next  set)  ,  the  curve  segments  are  not 
implicitely  connected.  If  the  number  of  points  in  the  point  list  is 
not  an  even  multiple  of  four,  then  only  those  point  sets  (if  any) 
that  contain  four  points  shall  be  used.  Any  remaining  points  shall 
be  ignored. 

Each  set  of  four  points  defines  the  shape  of  its  curve 
geometrically.  The  curve  starts  at  (Xg,  Yq)  ,  it  is  tangent  to  the 

line  from  (Xq,  Yq)  to  (Xi,  Y^)  at  that  point,  and  it  leaves  the 
point  in  that  direction.  The  curve  ends  at  (Xj,  Yj)  ,  it  is  tangent 
to  the  line  from(  Xj,  X^)  to  (X^,  Yq)  at  that  point,  and  it 
approaches  the  point  from  that  direction.  The  lengths  of  the  lines 
(^0/  ^0^  Y^)  and 

(Xj,  Xj)  to  (Xj,  Yj)  represent  in  some  sense  the  "velocity"  of  the 
path  at  the  endpoints .  The  curve  is  always  contained  in  the  convex 
hull  of  the  four  points. 

The  mathematical  foundation  of  a  Bezier  cubic  curve  is  derived  from 
a  pair  of  parametric  cubic  equations: 

+  Cj,c  +  Xfj 

y(t)  -  +  byt^  +  CyC  ^  Yq 

The  cubic  section  produced  by  Cubic  Bezier  Curve  is  the  path 
traced  by  x(t)  and  y<t)  as  t  ranges  from  0  to  1.  The  Bezier  control 
points  corresponding  to  this  curve  are: 


^1 

-  Xo 

•h 

Cx/3 

Xi  -  Xo  + 

Cy/3 

Xj 

yz  ~  Vi  ^ 

(Cy  +  by}/ 3 

-  ^0 

+ 

+  b^  + 

yj  -  Yo  + 

Cy  by  *  a 
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Relabionahip  bo  particular _ atandarda : 

1)  CGM  Functional  Specification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

A  functional  description  of  the  Bezier  curve  generalized  drawing 
primitive  parameters  is: 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 


point  liat(nP) 
data  record (D) 


Items  for  Data  Record; 

The  data  record  is  empty  (that  is,  it  is  a  null  string.) 

Data  Record  Description: 

The  data  record  is  empty. 

2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  6KS  Functional  Specification  (reference  ISO  7942  GKS 
Functional  Description) 

This  GDP  is  applicable  at  level  Oa  and  above.  It  will  use  the 
polyline  attribute  set.  The  control  points  are  transformed  to  NDC 
and  the  Bezier  curve  through  those  points  is  then  drawn.  A 
functional  description  of  its  input  parzuneters  is: 

Name  Coordinate  System  Values  Data  Type  Range 

number  of  points  (4)  I 

M  4-tuple3  of  Bezier  WC  Mx4xP  >0 

control  points 

GDP  identifier  as  assigned 

N 

GDP  data  record:  emotv 


Errors : 

5  GKS  not  in  proper  state;  GKS  shall  be  either  in  the  state 
WSAC  or  in  the  state  SGOP 

10.0  Number  of  points  is  invalid:  the  number  of  points  shall  be 
a  multiple  of  four  and  shall  be  greater  than  zero 

4)  GKS  FORTRAN  language  binding  (reference  ISO/IEC  8651-1,  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GDpqrs"  form 
(as  defined  in  subclause  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  GDP  (pqrs  is  to  be  assigned  by  the  Registration  Authority  to 
correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GDpqrs (  N,  PXA,  PYA  ) 

Input  Parameters : 

INTEGER  N  nvunber  of  points  (M*4) 

REAL  PXA(M*4),  PYA(M*4)  4— tuples  of  Bezier  control  points 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  GDP  through  the  GGDP  function  of  subclause  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Parameters  used  by  the  Pack  Data  Record  function  for  the  Input  Data 
Record: 

INTEGER  IL  0 
INTEGER  RL  0 
INTEGER  SL  0 

The  Unpack  Data  Record  function  is  not  required  by  this  escape. 
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5)  Pascal  language  binding  (reference:  ISO/IEC  8651-2  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GEscape"  as  defined  in  subclause  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 

NumPoints  -  M*4; 

Points  :  GAPointArray; 

GRGDPData  -  RECORD 

CASE  GDP Id  :  GTGDPDataTag  OF 
1:  ()/•  (*  null  data  record*) 

END; 


6)  GKS  Ada  language  binding  (reference  ISO/IEC  8651-3  GKS 
Language  Bindings;  Part  3:  Ada) 

Registered  GDP's  are  in  a  library  package  named  GKS_GDP .  GKS  Ada 
provides  a  data  type  package,  GKS_TYPES  which  provides  types 
declarations . 

The  binding  for  the  "procedure  BEZIER_CURVE"  form  (as  defined  in 
subclause  4 . 1  of  the  GKS  Ada  language^binding)  of  the  GDP  is : 


—GDP  function  for  a  Bezier  curve. 

— Data  type  GDP_  DATA_RECORD  is  defined  in  package  GKS_GDP . 

— GDP_ID  and  other  data  types  are  defined  in  package  GKS_TYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package  GKS_GDP  is 

type  BEZIER_POINTS  is  new  WC.POINT_ARRAY  (1...); 
procedure  BEZIER_CURVE 

(BEZIER_CONTROL_POINTS  ;in  BEZIER_POINTS; 

GDP  IDENTIFIER  :in  GDP  ID); 


— more  GDP  procedures  can  be  inserted  here 


end  GKS  GDP; 
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ProDosal  Numbar;  I  4 1 


Date  o(  Presentation:  I  10  Aoril  1987 


Autborltv:  I  ANSI 


iBaacEHini 


Class  of  Graphical  Item:  ! 

IGDP 

GDP  Identifier:  I  Conic  Arc 


Deecrlotlon 


A  bounded,  connected  portion  of  a  parent  conic  curve  is  defined  in  a  definition  space  and  then  transformed  into  an 
approipriate  standard>dependent  coordinate  system  by  the  conic  arc  transformation  matrix.  The  conic  arc 
transformation  matrix  is  defined  by  the  registered  escape  function  Set  Conic  Arc  Transformation  Matrix.  A 
Conic  Arc  is  a  line  primitiva  that  takas  line  attributes.  See  the  attached  sheets  for  a  detailed  description. 


Additional  Comments 


Justification  for  Inclusion 


Conic  arcs  are  commonly  found  in  proprietary  graphics  system.  They  are  needed  to  support  the  requirements  of 
office  document  and  engineering  drawing  exchange. 


_ Relationship  to  Standards 


1 )  ISO  7942  (GKS)  •  Specifies  a  registered  GOP  as  defined  in  5.3. 

2)  ISO  8632  (CGM)  •  Specifies  a  registered  GDP  as  defined  in  5.6.10. 

3)  ISO  8651  (GKS  Language  Bindings)  -  Specifies  a  registered  GDP.  (Sea  attached  sheets). 
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Conic  Arc 


Deaeripfcion: 


A  conic  arc  is  generated  which  is  defined  as  follows : 

A  conic  arc  is  a  bounded  connected  portion  of  a  parent  conic  curve 
which  consists  of  more  than  one  point .  The  parent  arc  is  either  an 
ellipse,  a  parabola,  or  a  hyperbola.  The  conic  arc  is  defined  by  a 
start  point,  P,  an  end  point,  Q,  and  six  parameters,  A,B,C,D,E,  and 
F.  The  conic  arc  itself  is  defined  by  the  six  parameters  and  the 
following  equation: 

A*Xt^  +  B*XtYt  +E*Yf^  +F  •  0 

where  (X^,  Yf-)  is  an  abstract  Cartesian  coordinate  system  called 

"definition  space".  In  order  for  the  conic  arc  to  be  processed 
correctly  by  the  receiving  system  given  the  above  presentation,  the 
conic  arc  entity  must  be  positioned  such  that  each  of  its  axes  is 
parellel  to  either  the  axis  or  Yf-  axis.  The  arc  is  then 

positioned  correctly  in  the  appropriate  computer  graphics 
coordinate  system  by  using  the  value  of  the  current  Conic  Arc 
Transformation  Matrix. 

To  determine  the  form  of  the  conic  arc,  the  quantities  Ql,  Q2  and 
Q3  are  defined  as  follows: 

02  ■  determinant  of  /  A  B/2  D/2  I 

I  B/2  C  E/2  I 
I  D/2  E/2  F  I 

Q2  -  determinant  of  I  A  B/2  I 

I  B/2  C  I 

03  -  A  +  C 

If  Q2>0  and  (02  *Q3) <0,  then  the  arc  is  elliptical. 

If  02<0  and  02<>0,  then  the  arc  is  hyperbolic. 

If  Q2’-0  and  02<>0,  the  the  arc  is  parabolic. 

If  02*0  or  if  both  Q2>0  and  (Q1*Q3)>“0,  the  results  are 
implementation  dependent. 

In  the  case  where  the  conic  arc  is  elliptical,  to  distinquish  the 
arc  in  question  from  its  complement,  the  direction  of  the  arc  with 
respect  to  the  definition  space  must  be  from  start  point  to  end 
point  in  a  counter-clockwise  direction. 

In  the  case  where  the  conic  arc  is  parabolic  or  hyperbolic,  the 
parameterization  defines  a  unique  portion  of  the  parabola  or  a 
unique  portion  of  a  branch  of  the  hyperbola,  thus,  the  direction  is 
irrelevant • 

The  direction  of  the  conic  arc  with  respect  to  the  space  where  it 
is  drawn  is  determined  by  the  original  direction  of  the  arc  in 
definition  space,  in  conjunction  with  the  action  of  the  current 
Conic  Arc  Transformation  Matrix. 
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Ralationahip  to _ pagtlCttlaC _ atandarda  ; 

1)  CGM  Functional  Spacification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

The  start  and  end  points  are  in  definition  space  and  are  always 
encoded  as  real  numbers.  The  arc  is  transformed  to  VDC  using  the 
current  Conic  Arc  Transformation  Matrix  and  is  then  drawn.  A 
functional  description  of  the  conic  arc  parameters  is: 

Parameters: 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

point  list(nP)  -  P/  Q 
data  record  (D) : 

A 

B 

C 

D 

E 

F 


Items  for  Data  Record: 

A 

B 

C 

D 

E 

F 

Data  Record  Description: 

The  data  record  contains  the  six  coefficients  of  the  defining 
equation. 

2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  GKS  Functional  Specification  (reference  ISO  7942  GKS 
Functional  Description) 


This  GDP  is  applicable  at  level  Oa  and  above.  It  will  use  the 
polyline  attribute  set.  The  arc  is  transformed  to  NDC  using  the 
current  Conic  Arc  Transformation  Matrix  and  then  drawn.  A 
functional  description  of  its  input  parameters  is : 


Mama  Coordinate  System 

number  of  points 


Values 

(2) 


Data  Type 

I 


GPD  identifier 


as  assigned  N 


GDP  data  record 

(conic  arc  coefficients) : 

A 

B 

C 

D 

E 

F 


R 

R 

R 

R 

R 

R 


Errors : 

5  GKS  not  in  proper  state:  GKS  shall  be  in  the  state 
WSAC  or  in  the  state  SGOP 

100  Number  of  points  is  invalid:  The  number  of  points  must  be 
two  (2)  . 

4)  GKS  FORTRAN  language  binding  (reference  ISO/IEC  8651-1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GDpqrs"  form 
(as  defined  in  subclause  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  GDP  (pqrs  is  to  be  assigned  by  the  Registration  Authority  to 
correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GDpqrs  (P,  Q,  A,  B,  C,  D,  E,  F) 

Input  Parameters : 

REAL  P(2),  Q{2)  conic  arc  endpoints 

REAL  A,  B,  C,  D,  E,  F  conic  arc  coefficients 
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b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  GOP  through  the  GGDP  function  of  subclause  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Parameters  used  by  the  Pack  Data  Record  function  for  the  Input  Data 
Record: 

INTEGER  IL  0 
INTEGER  RL  6 
REAL  RA(  1  )  A 
REAL  RA(  2  )  B 
REAL  RA(  3  )  C 
REAL  RA(  4  )  D 
REAL  RA(  5  )  E 
REAL  RA(  6  )  F 
INTEGER  SL  0 


The  Unpack  Data  Record  function  is  not  required  by  this  escape. 
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5)  Pascal  language  binding  (reference:  ISO/IEC  8651-2,  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GEscape”  as  defined  in  subclause  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  ”1**  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


NumPoints  -  2; 

GRGDPData  -  RECORD 

CASE  GDP Id  :  GTGDPDataTag  OF 
1:  ( 

UOOOl  CoefA  :  REAL; 
UOOOl  CoefB  :  REAL; 
UOOOl  CoefC  :  REAL; 
UOOOl  CoefD  :  REAL; 
UOOOl  CoefE  :  REAL; 
UOOOl  CoefF  :  REAL) ; 

END; 
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6)  GKS  Ada  languaga  binding  (reference  ISO/IEC  8651-3,  GKS 
Language  Bindings;  Part  3: Ada) 

Registered  GDP's  are  in  a  library  package  named  GKSjSDP.  GKS  Ada 
provides  a  data  type  package,  GKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  CONIC_ARC"  form  (as  defined  in 
subclause  4.1  of  the  GKS  Ada  language  binding)  of  the  GDP  is: 


— GDP  function  for  a  conic  arc. 

— Data  type  GDP_DATA_RECORD  is  defined  in  package  GKS_GDP. 

— GDP_1D  and  other  data  types  are  defined  in  package  GKS_TYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package  GKS_GDP  is 

type  CONIC_^ARC__DATA__RECORD  is  new  GDP__DATA__RECORD  (0,6,0); 
procedure  CONIC_ARC 

(CONIC_AjlC_RECORD  :  in  CONIC_ARC_DATA_RECORD)  ; 

— The  components  of  the  C0N1C__ARC_DATA_REC0RD  are  the  start  and  end 
— points  as  well  as  the  coefficients  specified  in  the  registration 
— procedure . 

— more  GDP  procedures  can  be  inserted  here 
end  GKS  GDP; 
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Date  of  Prasentatlon:  I  10  April  1987 


I  Sponsoring  Authority:  I  ANSI 

I  Clasa  of  Graphlcat  Item;  I  ESCAPE 

I  Specific  Escape  I  Function  Identifier:  I  Sat  Conic  Arc  Transformation  Matrix  I 

_ _ Deacription _ 

This  escape  function  sets  a  value  of  the  transformation  matrix  nsedsd  to  describe  how  a  conic  arc  described  by 
the  registered  GDP  Conic  Arc  is  moved  from  'definition  space*  to  a  standard-depended  graphic  coordinate 
system.  See  attached  sheets  for  a  detailed  description. 


Additional  Comments 

Nona. 


Justification  for  Inclusion 

Conic  arcs  are  commonly  found  in  proprietary  graphics  system.  They  are  needed  to  support  the  requirements  of 
engineering  drawing  exchange.  Due  to  various  numerical  problems,  such  curves  are  bast  specified  in  a  'definition 
space*  and  then  transformed  to  their  final  location  by  applying  a  transformation  matrix.  This  escape  function  is 
needed  to  supply  values  for  the  required  'modelling*  or  transformation  matrix. 


_ Relationship  to  Standards 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  GDP  as  defined  in  5.3. 

2)  ISO  8632  (CGM)  -  Specifies  a  registered  GOP  as  defined  in  5.6. 10. 

3)  ISO  8651  (GKS  Language  Bindings)  -  Specifies  a  GDP.  Sea  attached  sheets. 
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Set  Conic  Afu  Transfonnation  Matrix 


PAgetrtpfcion: 

This  escape  is  intended  to  work  in  conjunction  with  the  conic  arc 
generalized  drawing  primitive  to  transform  the  conic  arc  from 
definition  space  to  "drawing  space".  Drawing  apace  is  a 
standard-dependent  coordinate  system,  usually  World  Coordinates  for 
API  standards  and  Virtual  Device  Coordinates  for  metafile  and 
device  interface  standards .  The  conic  arc  trans format ion  matrix 
transforms  definition  space  point  coordinates  by  means  of  a  matrix 
multiplication.  This  transformation  is  performed  by  applying  the 
following  matrix  multiplication  to  coordinates: 

/  Rii  Ri2  R13  I  I  ^in  /  I  ^out  I 

I  R22  R22  R23  I  X  I  I  -  /  I 

I  1  I 

where  IRijI  is  the  transformation  matrix,  (Xin,Y±„)  is  the 
corrdinate  to  be  transformed  and  ^out^  i®  the  coordinate 

resulting  from  the  transformation.  Both  the  input  and  output 
coordinate  systems  are  assumed  to  be  orthogonal,  Cartesian  and 
right-handed.  The  default  transformation  matrix  is: 

I  1  0  0  I 

I  0  1  0  I 

[Note:  IGCS  version  3.0  defines  this  transformation  as  a  matrix 
multiplication  followed  by  a  vector  addition  (translation) .  To  be 
consistent  with  the  way  transformations  are  defined  in  computer 
graphics  standards,  an  equivalent  homogeneous  coordinate 
formulation  is  used  here  instead.  To  translate  this  form  to  the 
IGES  form,  simply  use  the  first  two  columns  of  the  above  matrix  as 
the  IGES  matrix  and  the  last  coltimn  as  the  "T-vector"  values  T1  and 
T2  in  IGES.) 


Set  Conic  Aic  Transfomialion  Matrix 


RftTafeionahip  to  particular _ atandarrta; 

1)  CGM  Functional  Specification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

This  matrix  is  used  to  transform  a  Conic  Arc  element  from  its 
definition  space  into  VDC  where  it  is  drawn.  A  functional 
description  of  the  Set  Conic  Arc  Transformation  Matrix  escape 
parameters  is: 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 


data  record  (D)  : 
Rll 
R12 
R13 
R21 
R22 
R23 

Items  for  Data  Record: 


Rii 

R12 

R13 

R21 

R22 

R23 

Data  Record  Description: 

The  parameters  define  a  2x3  matrix  used  to  transform  a  Conic 
Arc  element  from  its  definition  space  into  VDC  where  it  is  drawn. 

2}  CGM  Zncodlngs  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string’s  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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Set  Conic  Arc  Transformation  Matrix 


3)  6KS  Functional  Description  (reference  ISO  7942  GKS 
functional  description) 

This  escape  is  applicable  at  level  Oa  and  above.  A  functional 
description  of  its  parameters  is  given  below: 


Name  Values  Data  Type 

escape  function  identifier  as  assigned  N 

(transformation  matrix)  2X3XR 

Rll  R 

R12  R 

R13  R 

R21  R 

R22  R 

R23  R 


output  data  record: 
none 

Errors : 

5  GKS  not  in  proper  state:  GKS  shall  be  in  the  state 
WSAC  or  in  the  state  SGOP 
100  Number  of  points  is  invalid 


4)  GKS  FORTRAN  language  binding  (reference  ISO/IEC  8651-1/  GKS 
Language  Bindings ;  Part  1 :  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs”  form 
(as  defined  in  subclause  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (Rll,  R12,  R13,  R21,  R22,  R23) 

Input  Parameters : 

REAL  Rll  2X3  transformation  matrix 

REAL  R12 

REAL  R13 

REAL  R21 

REAL  R22 

REAL  R23 

Output  Parameters : 

NONE 
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b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Parameters  used  by  the  Pack  Data  Record  function  for  the  Input  Data 
Record: 

INTEGER  IL  0 
INTEGER  RL  6 
REAL  RA(  1  )  Rll 
REAL  RA(  2  )  R12 
REAL  RA(  3  )  R13 
REAL  RA(  4  )  R21 
REAL  RA(  5  )  R22 
REAL  RA(  6  )  R23 
INTEGER  SL  0 

The  Unpack  Data  Record  function  is  not  requir-a  oy  this  escape. 


5)  Pascal  language  binding  (reference:  ISO/IEC  8651-2  GKS 
Language  Bindings;  Part  2:  Pas-al) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GEscape"  as  defined  in  subclause  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


GREscapeDataIn  »  RECORD 

CASE  EscapelD  :  GTEscapeDataTag  of 
1:  ( 


END; 


UOOOl  MatrixRealll 
UOOOl  MatrixReall2 
UOOOl  MatrixReall3 
UOOOl  MatrixReal21 
UOOOl  MatrixReal22 
UOOOl  MatrixReal23 


REAL; 
REAL; 
REAL; 
REAL; 
REAL; 
REAL)  ; 


GREscapeDataOut  «  RECORD 

CASE  Escapeld  ;  GTEscapeDataTag  of 
1:  ()  ;  Null  Record*) 

END; 
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6)  6KS  Ada  Language  binding  (reference  ISO/IEC  8651-3,  GKS 
Language  Bindings;  Part  3: Ada) 

Registered  ESCAPE'S  are  in  a  library  package  named  GKS_ESCAPE-  GKS 
Ada  provides  a  data  type  package,  GKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SET_CONIC_ARC_TRANSFORMATION_ 
MATRIX"  form  (as  defined  in  subclause  4.1  of  the  GKS  Ada  language 
binding)  of  the  ESCAPE  is; 


— Escape  function  for  a  set  conic  arc  transformation. 

— Data  type  ESCAPE  ID  and  ESCAPE^FLOAT  are  defined  in  package 
~GKS_ESCAPE .  “ 

— Other  data  types  are  defined  in  package  GKS_TYPES. 


with  GKSJTYPES; 
use  GKSJTYPES; 
package^GKE^ESCAPE  is 

type  CONIC_TRANSFORM_MATRIX  is  array  (1..2,1..3)  of  BSCAPE_FLOAT; 

procedure  SET  CONIC  ARC  TRANSFORMAT10N_MATRIX 

(CONIC“aRC__MATRIX  :  in  CONIC_TRANSFORM_MATRIX  )  ; 

— The  components  of  C0NIC_ARC_DATA  are  the  2X3  transformation 
— matrix  specified  in  the  registration  proposal 


— more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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ProDosal  Number: I  43 


Data  of  Presentation:  i  10  April  1987 


Sponsorinq  Authorltv:  I  ANSI 


Class  of  Graoftleai  Item:  I GCP 


GOP  Identifier:  I  Parametric  Spline  Curve 


Description 


A  planar  (two  dimensional)  parametric  spline  curve  is  drawn.  A  parametric  spline  curve  |s  a  line  primitive  that 
takes  line  attributes.  Sea  attached  sheets  for  a  detailed  description. 


Additional  Comments 


Relationship  to  Standards 


1 )  ISO  7942  (GKS)  -  Specifies  a  registered  GDP  as  defined  in  5.3. 

2)  ISO  8632  (CGM)  -  Specifies  a  registered  GOP  as  defined  in  5.6.10. 

3)  ISO  8651  (GKS  Language  Bindings)  -  Specifies  a  registered  GDP.  (See  attached  sheets). 
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Parametric  Spline  Cunre 


Deaeription; 

A  paramatric  splina  curva  as  defined  below  is  drawn.  A 
parametric  spline  curve  is  a  sequence  of  parametric  polynomial 
segments .  The  curve  is  defined  using  the  following  parameters : 

curve  type  (E) 

N  (number  of  segments)  (I) 
r  (knot  sequence  for  polynomial)  ((N+1)R) 

X  coordinate  polynomial  list  (N  sets  of  four) 

Ax/Bx/t^x/^x  ((4*N)R) 

Y  coordinate  polynomial  list  (N  sets  of  four) 

Ay,  By,  Cy,  By  ( ( 4  *N)  R)  . 

This  parametrization  is  generalized  to  allow  for  the  representation 
of  many  different  parametric  spline  curves  using  this  one  element . 
The  curve  type  parameter  indicates  the  type  of  parametric  curve  as 
it  was  represented  in  the  sending  system  before  being  converted  to 
this  generic  form.  The  following  curve  types  are  defined: 

1)  linear 

2)  quadratic 

3)  cubic 

4)  Wilson-Fowler 

5)  modified  Wilson-Fowler 

6)  B  spline 

If  the  curve  type  is  not  one  of  the  defined  values,  the  default 
value,  linear,  shall  be  used. 

The  number  of  segments  parameter,  W,  is  the  number  of  polynomial 
segments  to  be  used  to  define  the  curve.  Each  segment  is  defined  by 

a  cubic  polynomial  in  X  and  Y  that  is  evaluated  using  the  eight 

polynomial  coefficients  associated  with  that  segment: 
Ax/ ^x/ ^x' Ay, By,  Cy, By.  Segment  i  is  delimited  by  its  knots,  T(i) 

and  T(i+1).  If  the  number  of  segments  is  less  than  one  (1),  the 
default  value,  one  (1),  shall  be  used. 

The  coordinates  of  the  points  of  the  i^h  segment  of  the  curve  are 
given  by  the  following  cubic  polynomial  equations.  Note  that 
coefficients  B,  or  C  and  B  will  be  zero  if  the  polynomials  are  of 
degrees  2  or  1,  respectively: 

X(u)  -  Ax(i)  +  B^(i}*s  t  Cx(l)*S^  +  D^d)  *s^ 

Y(U)  -  Ay(i;  +  By(±)*S  +  Cy(i)*s2  +  Dy(i)*S^ 

where  T(i)  <-  u  <-  T(i+1) ,  i~l,  .  .  .  ,N  and  s  -  u  -  r(i)  .  In  order  to 
avoid  degeneracy,  for  each  i  at  least  one  of  the  six  real 
coefficients  Bx,  C^r  D^,  By,  Cy,  Dy  must  be  non-zero.  If  the  knot 

sequence  or  the  Y  coordinate  polynomial  lists  are  invalid,  the 
results  are  implementation  dependent. 
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To  enable  determination  of  the  terminate  point  and  derivatives 
without  computing  the  polynomials,  the  polynomials  and 
derivatives  are  evaluated  at  u  -  T(N+1) .  These  data,  divided  by  the 
appropriate  factorial  (i.e.  the  second  derivative  divided  by  2!, 
the  third  by  31,  etc.),  are  used  as  the  or  terminate  point 
values . 
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Relationship _ tfi — Particular — standagda ; 

1)  COM  Functional  Specification  (reference  ISO  8632  COM; 

Part  1:  Functional  Description) 

The  parameters  of  the  curve  are  transformed  to  VDC  and  the  curve  is 
drawn.  A  functional  description  of  the  parametric  spline  curve 
parameters  is : 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

point  list  -  empty 
data  record  (D)  ;  - 

C  (curve  type)  (Note  1)  (E) 

N  (number  of  segments)  (I) 

T  ()cnot  sequence  for  polynomial)  ((N+1)R) 

X  coordinate  polynomial  list  (N  sets  of  four) 

AX, BX,CX,DX  ((4*N)R) 

Y  coordinate  polynomial  list  (N  seta  of  four) 

AY, aY,CY,DY  ((4*N)R). 

Mote  1:  Curve  type  is  one  of  (linear,  quadratic,  cubic, 
Wilson-Fowler,  modified  Wilson-Fowler,  B  spline) 


Items  for  Data  Record: 

C 

N 

T(l) 


T(N+1) 

AX(1) 

BX(1) 

CX(1) 

DX{1) 

AX(2) 

BX{2) 


AY(1) 

BY(1) 


Data  Record  Description : 

The  data  record  contains  the  parameters  needed  to  define  the 
parametric  spline  curve curve  type,  number  of  segments,  knot 
sequence  list,  and  the  coefficients  of  the  two  polynomials  that 
define  the  X  and  Y  coordinate  values,  respectively,  for  the  curve. 
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2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3/4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 


3)  GKS  Functional  Specification 

Functional  Description) 

(reference  ISO 

7942  GKS 

This  GDP  is  applicable  at  level  Oa  and  above.  It  will  use  the 

polyline  attribute  set.  The  parameters  of  the  curve  are 
transformed  to  NDC  and  the  curve  is  drawn.  A  functional 
description  of  its  input  parameters  is : 

Marne  Coordinate  System 

number  of  points 

Values 

(0) 

Data  Type 

I 

GDP  identifier 

as  assigned 

N 

GDP  data  record: 

see  IGES  attachments  for  definitions 

CTYPE 

Note  1 

I 

MSEG 

I 

knot  sequence  for 
polynomials 

(N+1)R 

X  coordinate  polynomial 
list 

(  (4*N)R) 

Y  coordinate  polynomial 
list 

(  {4*N)R)  . 

Mote  1:  Curve  type  is  one  of  (linear,  quadratic,  cubic, 
Wilson-Fowler,  modified  Wilson-Fowler,  B  spline) 


Errors : 

5  GKS  not  in  proper  state:  GKS  shall  be  in  the  state 
WSAC  or  in  the  state  SGOP 
100  Number  of  points  is  invalid 
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4)  G2CS  FORTRAN  language  binding  (reference  ISO/IEC  8651-1,  GKS 
Language  Bindings;  Part  1;  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GDpqrs"  form 
(as  defined  in  subclause  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  GDP  (pqrs  is  to  be  assigned  by  the  Registration  Authority  to 
correspond  to  the  assigned  Register  Identifier)  : 

SUBROUTINE  GDpqrs (  CTYPE,  NSEG,  T,  X,  Y  ) 

Input  Parameters : 

INTEGER  CTYPE  curve  type 

INTEGER  NSEG  number  of  polynomial  segments 

REAL  T(NSEG-)-l)  )cnot  sequence  list 

REAL  X (NSEG, 4)  X  coordinate  polynomial  coefficients 

REAL  Y (NSEG, 4)  Y  coordinate  polynomial  coefficients 

The  following  mnemonic  FORTRAN  names  and  their  values  for  GKS 
ENUMERATION  type  values  are  added  to  the  list  in  the  GKS  FORTRAN 
binding: 

curve  type  linear,  quadratic,  cubic,  Wilson-Fowler, 

modified  Wilson-Fowler,  B-spline 
INTEGER  GLIN,  GQUAD,  GCUBIC,  GWLFOW, 

GMWLFOW,  GBSPLN 

PARAMETER  (GLIN-1,  GQDAD-2,  GCUBIC-3,  GWLFOW-4, 

GMWLFOW-5,  GBSPLN-6) 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  GDP  through  the  GGDP  function  of  subclause  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Parameters  used  by  the  Pack  Data  Record  function  for  the  Input  Data 
Record: 

Integer  IL  2 
Integer  IA(1)  C 
Integer  IA(2)  N 
Integer  RL  (9N+1)R 
Real  RA(1)  T(l) 

Real  RA(N+1)  T(N+1) 

Real  RA(N-t-2)  AX(1) 

Real  RA(N+3)  BX{1) 

Real  RA{N+4)  CX(1) 

Real  RA(N+5)  DX(1) 

Real  RA(N+6)  AX  (2) 

Real  RA(N+7)  BX(2) 

Real  RA(5N+2)  AY(1) 

Real  RA(5N+3)  BY(1) 

Integer  SL  0 

The  Unpack  Data  Record  function  is  not  required  by  this  escape. 


208 


Parametric  Spline  Curve 


5)  Pascal  language  binding  (reference:  ISO/IEC  8651-2,  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  Is  proposed  for  the  procedure 
"GEscape”  as  defined  In  stibclause  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1”  will  be  replaced  with  the  actual 
ESCAPE  Identifier  at  registration) : 


GEGDPCurvePropertyS  -  (linear,  quadratic,  cubic, 

Wilson-Fowler,  modified  Wilson-Fowler, 
B-spllne) ; 


GRGDPData  -  RECORD 

CASE  GDPId  :  GTGDPDataTag  OF 
1:  ( 

00001  CType  :  GEGDPCurvePropertyS; 
00001  NSeg  :  INTEGER; 

00001  T  :  array  [1 . . (NSeg+1) ]  of  REAL; 

00001  X  :  array  [1 . . (4*NSeg) 1  of  REAL; 

OOOOl  Y  :  array  [1 . . (4*NSeg) ]  of  REAL) ; 

END; 
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6)  6KS  Ada  language  binding  (reference  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part  3:  Ada) 

Registered  GDP ' s  are  in  a  library  package  named  GKS_GDP .  GKS  Ada 
provides  a  data  type  package#  GKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  PARAMETRIC_SPLINE_CURVE"  form  (as 
defined  in  Paragraph  4.1  of  the  GKS  Ada  language  binding)  of  the 
GDP  is: 


— GDP  function  for  a  parzunetric  spline  curve  gap. 

— Data  type  GDP_DATA_RECORD  is  defined  in  package  GKS_^GDP . 

— GDP_ID  and  other  data  types  are  defined  in  package  GKS_TYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package  GKS_GDP  is 

type  CURVE_TYPE  is  (linear,  quadratic,  cubic,  Wilson-Fowler, 
modified  Wilson-Fowler,  B-spline) ; 
type  KNOTS  is  array  (SMALL  NATURAL  rangeo)  of 
ESCAPE  FLOAT; 

type  SPLINEj:URVE_DATA_RECORD  (NOM_SEG  :  SMALL_NATURAL  0)is 
record  ”  “ 

SPLINE  TYPE  :  CURVE_TYPE; 

KNOT  SEQUENCE  :  KNOTS  (1. . (NUM_SEG+1) ) ; 

POLYNOMIALS  :  POLYNOMIAL_ARRAY  ( 1 . . NUM_SEG , 1 . . 4 ) ; 

end  record; 

procedure  PARAMETRIC_SPLINE_CURVE 

(SPLINE_CURVE__RECORD  :  in  SPLINE_CURVE_DATA_RECORD )  ; 

— The  components  of  the  SPLINE_CURVE_DATA__RECORD  are  those 
— specified  in  the  registration  proposal. ^ 

— more  GDP  procedures  can  be  inserted  here 

end  GKS  GDP; 
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ProDosal  Number  I  44 


Data  of  Presentation:  I  10  Aoril  1987 


Sponsorlno  Authorit 


Class  of  Graphical  Item:  I GCP 


GOP  Identifier:  I  Rational  B>Splina  Curve 


Description 


A  planar  (two  dimsrwional)  rational  spline  B*splina  curve  is  drawn.  A  rational  B>spline  curve  is  a  line  primitive 
that  takes  line  attributes.  Sea  attached  sheets  for  a  detailed  description. 


A  ditlonal  Comments 


_ Justification  for  Inclusion 


Rational  B*splins  curves  are  commonly  found  in  proprietary  graphics  system.  They  are  needed  to  support  the 
requirements  of  engineering  drawing  exchange. 


_ Relationship  to  Standards 


1'  ISO  7942  (GKS)  •  Spscifies  a  registered  GOP  as  defined  in  5.3. 

2)  ISO  8632  (CGM)  -  Specifies  a  registered  GOP  as  defined  in  5.6.10. 

3)  ISO  8651  (GKS  Language  Bindings)  -  Specifies  a  registered  GOP.  (See  attached  sheets). 
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Daaerlpfcion: 

A  rational  B-s''>lln«  curve  as  defined  below  is  drawn .  T^e  curve 
is  defined  using  the  following  parameters: 

K  (upper  index  of  summation)  (I) 

M  (degree  of  the  basis  functions)  (I) 

curve  open  (one  of :  open,  closed)  (E) 

equation  type  (one  of:  rational,  polynomial)  (E) 

T  (icnot  sequence)  ((K+M+1)R) 
ff  (weights)  ((K+1)R) 

P  (control  points)  ((K+1)P) 
start  param  ^end  param  (2R) 

The  parametric  equation  governing  the  definition  of  the  rational 
B-spline  curve  is  shown  in  the  following  expression: 

K 

^»a)P<l)b^  (t) 


^ft(l)b^  (t) 

i-O 


where  U(i)  are  the  weights,  P(i)  are  the  control  points  and  b^  are 
the  basis  functions . 

The  B-spline  basis  functions,  bi^  are  non-negative  piecewise 
polynomials  of  degree  M.  T  is  a  non-decreasing  sequence  of  real 
numbers  T (-M) ,  .  .  . ,  T (0) ,  . .T  (K+1) .  Each  function  b^  is  supported  by 
the  knot  sequence  interval  [T (i-M) ,  T  (1+1)  J .  Between  any  two 
adjacent  knot  values,  T(j)  and  T(j+1),  the  corresponding  basis 
function  can  be  expressed  as  a  single  polynomial  of  degree  M. 

The  curve  itself  is  parametrized,  with: 

start  param  <*  t  <»  end  param, 

T(0)  <  start  param  <  end  pareua  <—  T(N) 

Thus,  for  any  parameter  value  t  between  T(0)  and  T(K+1),  the  sum  of 
the  basis  functions  satisfies  the  following  identity: 

K 

i-0 


The  B-Spline  basis  functions  themselves  are  defined  as  follows.  Let 


N(t 


t  t 


denote  the  B-spline  basis  function  of  degree  m  supported  on  the 
interval  ti+2/ • 
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The  degree  k  functions  are  defined  in  terms  of  those  of  degree  k-1 
as  follows : 


N(t 


s> 


. xj  I  5, . 5,^ 


h.r^o 


^k'^i 


Since  some  denominators  will  be  0  in  the  case  of  multiple  knots, 
the  convention  0/0  -  0  is  adopted  in  the  above  definition. 

If  the  knot  sequence,  weights,  or  control  points  are  invalid  (i.e. 
they  are  not  consistent  or  do  not  match  the  equation  type)  the 
results  are  implementation  dependent.  If  start  param  is  greater 
than  end  param,  no  curve  shall  be  drawn.  If  the  equation 

If  the  beginning  and  ending  points  of  the  curve  are  identical,  then 
curve  open  is  set  to  closed,  otherwise,  it  is  set  to  open.  If  curve 
open  is  not  one  of  the  defined  values,  then  the  default  value, 
open,  shall  be  used.  When  curve  open  is  closed,  and  the  derived 
curve  end  points  are  not  equal,  the  curve  end  points  shall  be 
forced  to  be  equal  by  an  implementation  dependent  method. 

If  all  of  the  weights  (i.e.  elements  of  the  weights  array,  W  )  are 
not  equal,  then  equation  type  is  set  to  rational.  Otherwise,  if  all 
of  the  weights  are  equal,  then  the  weights  cancel,  the  denominators 
sum  to  one  and  the  equation  type  becomes  polynomial.  If  equation 
type  is  not  one  of  the  defined  values,  then  the  default  value, 
rational,  shall  be  used.  If  the  value  of  equation  type  is  not 
consistent  with  the  weight  values,  then  the  type  equation  inplied 
by  the  weight  values  shall  be  substituted. 
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to  par-fcieular _ atandagd; 

1)  C6M  Functional  Specification  {reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

The  parameters  of  the  curve  are  transformed  to  '/DC  and  the  curve  is 
then  drawn.  A  functional  description  of  the  rational  B-spline 
parameters  is : 

Parameters: 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

point  list(nP)  -  contains  the  control  points 

data  record  (D) : 

K  (upper  index  of  sum)  (I) 

M  (degree  of  the  basic  functions)  (I) 
curve  open  (one  of:  open^  closed)  (E) 
equation  type  (one  of:  rational^  polynomial  (E) 

T  (knot  sequence)  ((K+M+1)R) 

W  (weights)  ((K+1)R) 

P  (control  points)  ({K+1)P) 
start  param,  end  param  (2R) 


Items  for  Data  Record: 

K 

M 

curve  open 
equation  type 
T(-M) 

T(-M+l) 

T{K+1) 

W(0) 

W(K+1) 
start  param 
end  param 

Data  Record  Description: 

The  data  record  contains  the  parameters  that  define  the 
rational  B-spline  curve:  the  upper  index  of  summation,  the  basis 
functions,  curve  open,  equation  type,  the  knot  sequence,  the 
weights,  and  two  parameters  —  start  param  and  end  param  —  that 
determine  the  beginning  and  end  of  the  curve. 
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2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2/3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string”,  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 

3)  GK3  runctional  Specification  (reference  ISO  7942  GKS 
Functional  Description) 

This  GDP  is  applicable  at  level  Oa  and  above.  It  will  use  the 
polyline  attribute  set.  The  control  points  are  transformed  to  NDC 
and  the  curve  is  drawn.  A  functional  description  of  its  input 
parameters  is: 


Name  Coordinate  System  Values 

number  of  points 

control  points  WC 

GDP  identifier  as  assigned 

GDP  data  record: 


Data  Type 

I 

nxP 

N 


K  (upper  index  of  summation)  I 
M  (degree  of  basis  functions)  I 
CUROPN  (open, closed)  E 
EQNTYP  (rational, polynomial)  E 
T  R 
W  R 
SPARAM,  EPARAM  r 


Errors : 

5  GKS  not  In  proper  state:  GKS  shall  be  in  the  state 
fiSAC  or  in  the  state  SGOP 
100  Humber  of  points  is  invalid 
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4)  gys  FORTRAN  language  binding  (reference  ISO/IEC  8651-1/  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GDpqrs"  form 
(as  defined  in  subclause  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  GDP  (pqrs  is  to  be  assigned  by  the  Registration  Authority  to 
correspond  to  the  assigned  Register  Identifier) ; 

SUBROUTINE  GDpqrs (N,  PXA,  PYA/  K,  M,  CUROPN,  EQNTYP,  T, 

+  W/  SPARAM/  EPARAM) 


Input  Parameters : 
INTEGER  N 

REAL  PXA(*)/  PYA(*) 
INTEGER  K 
INTEGER  M 
INTEGER  CUROPN 
INTEGER  EQNTYP 
REAL  T(  N+2M  ) 

REAL  W(  K  ) 

REAL  SPARAM, EPARAM 


nvimber  of  control  points 
control  points 
upper  index  of  summation 
degree  of  basis  functions 


knot  sequence 
weight 

determines  start  and  end  points 


The  following  mnemonic  FORTRAN  names  and  their  values  for  GKS 
ENUMERATION  type  values  are  added  to  the  list  in  the  GKS  FORTRAN 
binding: 


curve  open 

INTEGER 

PARAMETER 


open, 

GCROPN, 

(GCROPN-0, 


closed 

GCRCLO 

GGCRCLO-1) 


equation  type 

INTEGER 

PARAMETER 


rational, 
GEQRAT, 
(GEQRAT  -0, 


polynomial 
GEQPOL 
GEQRAT  -1) 
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b)  The  following  parameter 5  are  proposed  for  use  when  accessing 
this  GDP  through  the  6GDP  function  of  stibclause  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Parameters  used  by  the  Pack  Data  Record  function  for  the  Input  Data 
Record : 


Integer  IL  4 
Integer  IA(1)  K 
Integer  IA(2)  M 
Integer  IA(3)  COROPN 
Integer  IA(4)  EQNTYP 
Integer  RL  2K  +  M  +  4 
Real  RA(1)  T(-M) 

Real  RA(2)  T(-M+l) 

•  •  •  • 

Real  RA(K+M+1)  T(K+1) 

Real  RA(K+M-l-2)  H(0) 

Real  RA(2K-»-M+2)  W(K-i-l) 

Real  RA(2K+M+3)  SPARAM 
Real  RA(2K+M-i-4)  EPARAM 
Integer  SL  0 

The  Unpack  Data  Record  function  is  not  required  by  this  escape. 

5)  Pascal  language  binding  (reference:  ISO/IEC  8651-2,  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GEscape"  as  defined  in  subclause  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


GEGDPCurveProperty2  -  (GVGDPOpen,  GVGDPClosed) ; 
GEGDPCurvePro‘perty3  -  (GVGDPRational,  GVGDPPolynomial)  ; 


Points 


GAPointArray;  (^control  points*) 


GRGDPData  «  RECORD 

CASE  GDP Id  :  GTGDPDataTag  OF 
1:  ( 

UOOOl  K 
UOOOl  M 

UOOOl  CurveOpen 
UOOOl  EquationType 
UOOOl  T 
UOOOl  W 

UOOOl  StartParam 
UOOOl  EndParam 


INTEGER; 

INTEGER; 


GEGDPCurveProperty2 ; 
GEGDPCurveProperty3 ; 
REAL; 

REAL; 

REAL; 

REAL; ) 
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6)  6KS  Ada  language  binding  (reference  ISO/IEC  8651-3,  GKS 
Language  Bindings;  Pari.  3:  Ada)' 

a)  Registered  GDP's  are  In  a  library  package  named  GKS_GDP .  GKS 
Ada  provides  a  data  type  package,  GKS_TY?ES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  Rational_B__SPLINE_(njRVE"  form 
(as  defined  in  subclause  4.1  of  the  GKS  Ada  Izuiguage  binding)  of 
the  GDP  is: 


— GDP  function  for  a  rational  B__Spline  curve. 

“Data  type  GDP_DATA_RECORD  is  defined  in  package  GKS_GDP. 

— GDP_ID  and  other  data  types  are  defined  in  package  GKS_TYPES. 


with  GKS-TYPES; 
use  GKS-TYPES; 
package  GKS_GDP  is 

type  CURVE  OPEN_TYPE  is  (OPEN,  CLOSED) ; 

CURVE_OPEN“vALUE  ;  in  CURVEjOPENJTYPE; 

type  EQUATION  TYPE  is  (RATIONAL,  POLYNOMIAL)  ; 

EQUATION_VALUE  :  in  EQUATION__TYPE; 

type  KNOT  SEQUENCE__ARRAY  is  array  (SMALL  NATURAL  rangeo)  of 
ESCAPE_FLOAT; 

type  WEIGHT  SEQUENCE_ARRAY  is  array  (SMALL  NATURAL  rangeO)  of 
ESCAPE  FLOAT; 


type  RATIONAL_B_SPLINE_DATA_RECORD  is 
record 


UPPER  INDEX_OF_SUM 
DEGREE_OF_BAS  IS_FUNCTI0N5 
CURVE  0PEN_VALUE 
EQUATION_VALUE 
KNOT_SEQUENCE 
WEIGHT  SEQUENCE 
START  PARAM 
END_PARAM 
end  record; 


INTEGER; 

INTEGER; 

CURVE_OPEN_TYPE ; 
EQDATION_TYPE; 
KNOT_SEQUENCE_ARRAY ; 
WEIGHT_SEQUENCE  ARRAY; 
ESCAPE_FLOAT;  ” 
ESCAPE  FLOAT; 


procedure  RATIONAL_B_SPLINE_CURVE 

(CONTROL_POINTS  “  :in  WC. POINT  ARRAY; 

RATIONAL__B_SPLINE_DATA__RECORD  tin  GDP  DATA  RECORD); 


— The  components  of  the  RATIONAL_B_SPLINE_DATA_RECORD  are  those 
— specified  in  the  registration  proposal. 


— more  GDP  procedures  can  be  inserted  here 


end  GKS  GDP; 
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PART  2 

REVISED  PROPOSALS  FROM  LETTER  BALLOT  #76. 
TEXT  READY  FOR  REVIEW  AMD  THEN  RE-BALLOTTING. 


Proposal  Numbers  45 


Data  ot  Presentation:  I  10  April  1987 


Authorltv:  I  ANSI 


Class  ot  Q  iptilcal  item:  I  ESCAPE 


Specific  Escape  Function  Identifier:  Set  Edge  Mitre  Limit 


Description 


This  escape  function  sets  a  vaiua  for  the  current  edge  mitre  limit  This  value  determines  the  shape  put  at 
comers  between  consecutiva  edges  of  filled  area  graphical  primitivas.  Its  purpose  is  to  place  a  limit  on  how  long 
a  'spike*  can  emanate  from  the  join  of  two  portions  of  an  edge  of  a  filled  area  primitiva  by  'truncating*  long 
mitre  joins  into  bevel  joins.  Sea  attached  sheets  for  additional  details. 


Additional  Comments 


_ _ Justification  for  Inclusion 


User  specified  mitre  limits  are  commonly  found  in  proprietary  graphics  systems.  They  are  needed  to  support  the 
requirements  of  office  document  exchange  and  publishing. 


Relationship  to  Standards 


1)  ISO  7942  (GKS)  -  Not  applicable. 


2)  ISO  8632  (COM)  -  Specifies  a  registered  escape  as  defined  in  5.8.1. 

3)  ISO  8651  (GKS  Language  Bindings)  •  Not  applicable. 
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Set  Edge  Mttre  Limit 


Da-icription; 

Set  Edge  Mitre  Limit  sets  the  edge  mitre  limit  value  used  in 
interpretation  of  filled  area  primitives  to  mitre  length  specifier, 
which  must  be  a  number  greater  than  or  equal  to  1.  Mitre  limit  is  a 
dimensionless  number  that  controls  the  treatment  of  corners  between 
portions  of  edges  of  filled  area  primitives  when  mitre  joins  have 
been  specified.  A  related  registered  escape^  Set  Edge 
Join,  controls  the  type  of  join  that  is  selected.  When  portions 
connect  at  a  sharp  angle,  a  mitre  join  results  in  a  spike  that 
extends  well  beyond  the  connection  point.  The  purpose  of  the  mitre 
limit  is  to  cut  off  such  spikes  when  when  they  become  objectionably 
long.  If  the  mitre  length  specifier  is  less  than  or  equal  to  1,  the 
default  value  of  1  shall  be  used. 

At  any  given  corner,  the  mitre  length  is  the  distance  from  the 
point  at  which  the  inner  edges  intersect  to  the  point  in  which  the 
outside  edges  intersect  (i.e.,  the  diagonal  length  of  the  mitre). 
This  distance  increases  as  the  angle  between  the  edges  decreases . 
Whenever  the  ratio  of  the  mitre  length  to  the  line  width  exceeds 
the  edge  mitre  limit  parameter  and  is  also  greater  than  1.415,  a 
bevel  is  introduced  at  the  join  perpendicular  to  the  angle  bisector 
and  at  the  mitre  limit.  (Note  that  this  is  not,  in  general 
equivalent  to  introducing  a  bevel  jnln  when  this  limit  is  reached. 
Introducing  such  a  join  causes  discontinous  behaviour,  where  small 
changes  in  the  angle  between  the  segments  results  in  radically 
different  appearances.)  Whenever  the  ratio  of  the  edge  mitre  length 
to  the  edge  width  exceeds  the  edge  mitre  limit  parameter  and  is 
also  less  than  or  equal  to  1.415  (that  is,  when  the  edge  mitre 
limit  parameter  is  between  1  and  1.415  inclusive),  a  bevel  join  is 
implemented  at  the  mitre  limit . 

The  ratio  of  edge  mitre  length  to  edge  width  is  directly  related  to 
the  angle  ^  between  the  segments  by  the  formula: 


mitre  length  /  line  edge  -  1  /  sin  (^2) 

Examples  of  mitre  length  specifier  values  are:  1.415  cuts  off 
mitres  (converts  them  to  bevels)  at  angles  less  than  90  degrees, 
2.0  cuts  off  mitres  at  angles  less  than  60  degrees,  and  10.0  cuts 
mitres  off  at  angles  less  than  11  degrees .  The  default  value  of 
edge  mitre  limit  is  10.  Setting  the  edge  mitre  limit  to  1  cuts  off 
mitres  at  all  angles  so  that  bevels  are  always  produced  even  when 
mitres  are  specified.  The  lengths  in  the  above  formula  must  be  in 
the  same  units  (WC,  VDC,  etc.)  and  cancel  out  to  yield  a 
dimensionless  mitre  length  specifier  value.  This  escape  applies  to 
filled  area  primitives. 
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Set  Edge  Mftra  Liinit 


Ralationahip — PaC^iCRlar atandarrtw  ? 

1)  CGH  Functional  Specification  (reference  ISO  8632  CGM; 

Part  1 :  Functional  Description) 

A  functional  description  of  the  Set  Edge  Mitre  Limit  escape 
parameters  is : 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 

mitre  length  specifier (R) 

Items  for  Data  Record: 

mitre  length  specifier 

Data  Record  Description: 

The  parameter  defines  the  mitre  length  specifier. 

2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  Last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items), 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 

3)  6RS  Functional  Specification  (reference  ISO  7492,  GKS 
Functional  Specification) 

This  escape  does  not  apply  to  GKS  since  GKS  does  not  have  separate 
edge  attributes. 

4)  GKS  FORTRAN  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

This  escape  does  not  apply  to  GKS  since  GKS  does  not  have  separate 
edge  attributes. 

5)  GKS  Pascal  language  binding  (reference:  ISO/IEC  8651-2, 

GKS  Language  Bindings;  Part  2:  Pascal) 

This  escape  does  not  apply  to  GKS  since  GKS  does  not  have  separate 
edge  attributes. 
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Set  Edge  Mitre  Limit 


6)  GKS  Ada  language  binding  (reference  ISO/IEC  8651-3,  GKS 
Language  Bindings;  Part  3: Ada) 

This  escape  does  not  apply  to  GKS  since  GKS  does  not  have  separate 
edge  attributes . 
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Proposal  Numb«r;|46 


Date  of  Prasantatton:  I  10  April  1987 


Sponsortnq  Authority:  I  ANSI 


Class  ot  Graphical  Item:  I  ESCAPE 


Specific  Escape  I  Function  Identifier:  ISelEdaeC 


Description 


This  escape  (unction  sets  a  value  for  the  current  edge  cap.  This  value  is  used  to  determine  the  shape  put  at  the 
comers  where  consacutive  edges  of  filled  area  gr^hicai  primitivas  meet  Sea  attached  sheet  for  additional 
details. 


Additional  Comments 


_  _ Justification  for  Inclusion 


User  specified  edge  caps  are  commonly  found  in  proprietary  graphics  systems.  They  are  needed  to  support  the 
requirements  of  office  document  exchange  and  publishing. 


Relationship  to  Stanoards 


1)  ISO  7942  (GKS)  •  Not  applicable. 


2)  ISO  8632  (CGM)  •  Specifies  a  registered  escape  as  defined  in  5.8.1. 

3)  ISO  8651  (GKS  Language  Bindings)  -  Not  applicable. 
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Set  Edge  Cap 


Deaeripfeion: 

Sat  Edga  Cap  selects  the  edge  cap  value  specified  by  the  edge  cap 
indicator.  This  value  determines  the  shape  to  be  put  at  "corners" 
of  the  edgde  of  filled  area  primitives.  The  shape  is  not  applied 
to  the  ends  of  individual  "dashes”  that  compose  some  edgetypes.  The 
following  edge  cap  values  are  defined  with  this  proposal: 

butt  cap  :  the  edge  is  squared  off  at  the  endpoint;  there  is 
no  projection  beyond  the  endpoint. 

round  cap  :  a  semicircular  arc  with  diameter'  equal  to  the 
edge  width  is  drawn  around  the  corner  point  and  filled.  The 
drawn  line  thus  projects  beyond  the  corner  point. 

projecting  square  cap  the  edge  is  squared  off  at  a 
distance  equal  to  half  the  edge  width  beyond  the  corner 
point . 

If  the  edge  cap  value  is  not  one  of  the  defined  values,  the  default 
value,  butt  cap,  shall  be  used. 

Relationship  to _ partieular  standards; 


1}  CGM  runctional  Specification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

A  functional  description  of  the  Set  Edge  Cap  escape  parameters  is: 
Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 

edge  cap  indicator  (E) 


Items  for  Data  Record: 
edge  cap  indicator 

The  following  edge  cap  indicator  values  are  defined: 

1 :  butt  cap 
2 :  round  cap 

3:  projecting  square  cap 


Data  Record  Description: 

The  parameter  defines  the  edge  cap  indicator. 


Set  Edge  Cap 


2}  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2/3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 

3)  6KS  Functional  Specification  (reference  ISO  7492,  GKS 
Functional  Specification) 

This  escape  does  not  apply  to  GKS  since  GKS  does  not  have  separate 
edge  attributes . 

4)  GKS  FORTRAN  language  binding  (reference  ISO/IEC  8651-1,  GKS 
Language  Bindings ;  Part  1 :  FORTRAN) 

This  escape  does  not  apply  to  GKS  since  GKS  does  not  have  separate 
edge  attributes. 

5)  GRS  Pascal  language  binding  (reference:  ISO/IEC  8651-2, 

GKS  Language  Bindings;  Part  2:  Pascal) 

This  escape  does  not  apply  to  GKS  since  GKS  does  not  have  separate 
edge  attributes. 

6)  GRS  Ada  language  binding  (reference  ISO/IEC  8651-3,  GKS 
Language  Bindings;  Part  3:Ada) 

This  escape  does  not  apply  to  GKS  since  GKS  does  not  have  separate 
edge  attributes . 
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Proposal  Number; I  47 


Date  of  Prasantatlon:  I  10  Apnl  1987 


Sponsorinq  Authorltv:  I  ANSI 


Class  of  Graphical  Item:  I  ESCAPE 


Specific  Escape  I  Function  Identifier:  ISetEdaeJoin 


Description 


This  escape  function  sets  a  value  for  the  current  edge  jom.  This  value  determines  the  shape  put  at  comers 
between  consecutive  edges  of  filled  area  graphical  primitives.  See  attached  sheet  for  additional  details. 


Additional  Comments 


_  _  _  _  Justification  for  Inclusion 


User  specified  edge  joins  are  commonly  found  in  proprietary  graphics  systems.  They  are  needed  to  support  the 
requirements  of  office  document  exchange  and  publishing. 


1)  ISO  7942  (GKS)  -  Not  applicable. 


Relationship  to  Standards 


2)  ISO  6632  (CGM)  •  Specifies  a  registered  escape  as  defined  In  5.6.1. 

3)  ISO  8651  (GKS  Language  Bindings)  •  Not  applicable. 
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Set  Ed&b  woin 


Deaeription: 

Sat  Edga  Join  sets  the  current  edge  join  value  t-  edge  join 
indicator.  This  establishes  the  shape  to  be  put  at  the  corners 
between  portions  of  edges  of  filled  area  primitives.  The  following 
edge  join  values  are  defined: 

aitre  join  :  the  outer  edge  of  the  two  portions  are  extended 
until  they  meet  at  a  point.  (Note  that  the  mitre  limit  value 
may  affect  the  appearance  of  these  joins.) 

round  join  :  a  circular  arc  with  diameter  equal  to  the  edge 
width  is  drawn  around  the  vertex  between  the  adjoining 
segments  and  is  filled  in^  producing  a  rounded  corner. 

bevel  join  :  the  meeting  portions  are  finished  with  butt  end 
cap  and  the  resulting  triangular  notch  is  filled  in. 

If  the  edge  join  indicator  is  not  one  of  the  defined  values,  the 
default  value,  mitre  join,  shall  be  used. 

Join  styles  are  significant  only  at  points  where  consecutive  edges 
of  filled  area  primitives  connect  at  an  angle;  portions  that  meet 
or  intersect  fortuitously  receive  no  special  treatment. 
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Relationship — Particular — Standards  ; 

1)  CGM  Functional  Specification  (reference  ISO  8632  CGM; 

Part  1;  Functional  Description) 

A  functional  description  of  the  Set  Edge  Join  escape  parameters  is: 
Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 

edge  join  indicator  (E) 

Items  for  Data  Record: 

edge  join  indicator 

The  following  values  of  edge  join  indicator  are  defined: 

1 :  mitre  join 
2 :  round  join 
3 :  bevel  join 

Data  Record  Description: 

The  parameter  defines  the  edge  join  indicator  value. 

2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  males  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items), 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 

3)  GKS  Functional  Specification  (reference  ISO  7492,  GKS 
Functional  Specification) 

This  escape  does  not  apply  to  GKS  since  GKS  does  not  have  separate 
edge  attributes. 

4)  GKS  FORTRAN  language  binding  (reference  ISO/IEC  8651-1,  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

This  escape  does  not  apply  to  GKS  since  GKS  does  not  have  separate 
edge  attributes. 
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Set  Edge  Join 

5)  GKS  Pascal  language  binding  (reference:  ISO/IEC  8651-2, 

GKS  Language  Bindings;  Part  2:  Pascal) 

This  escape  does  not  apply  to  GKS  since  GKS  does  not  have  separate 
edge  attributes. 

6)  GKS  Ada  language  binding  (reference  ISO/IEC  8651-3,  GKS 
Language  Bindings;  Part  3: Ada) 

This  escape  does  not  apply  to  GKS  since  GKS  does  not  have  separate 
edge  attributes. 
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Date  of  Presentation:  I  18  July  1988 


SDonsorlnq  Authorit 


Class  at  Craphleal  Item:  I  ESCAPE 


Specific  Escape  I  Function  Identifier:  I  Select  Typeface  Posture 


Description 


Select  Typeface  Posture  selects  a  desired  typeface  posture.  This  information  is  used  to  indicate  a  preference  for 
one  posture  over  others  when  a  typeface  is  selected  during  *font  substitution*  or  when  a  graphical  font*  is  not 
completely  specified  in  a  typographic  sense.  See  attached  sheet  for  addittonai  details.  . 


Additional  Comments 


This  escape  is  intended  for  interim  use,  pending  the  revision  of  the  text  model  in  computer  graphics  standards 
based  upon  the  developing  ISO  font  architecture  (OIS  9541). 


Justification  for  Inclusion 


Extensions  to  the  text  model  in  computer  graphics  standards  are  urgently  needed  if  such  standards  are  to  be 
usable  in  office  systems  and  graphic  arts  applications.  Most  proprietary  graphics  systems  currently  use  a 
typographic  text  model  that  includes  a  posture  attribute.  This  escape  allows  the  posture  of  a  typeface  to  be 
selected  for  font  substitution  or  selection  purposes. 


Relationship  to  Standards 


1)  ISO  7942  (GKS)  ■  Specirtes  a  registered  escape  as  defined  in  5.2. 

2)  ISO  8632  (COM)  •  Specifies  a  registered  escape  as  defined  in  5.8.1. 


3)  ISO  8651  (GKS  Language  Bindings)  -  Specifies  a  registered  escape. 
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Select  Typeface  Posture 


Deaeription: 

Salect  Typeface  Posture  sets  the  desired  typeface  posture  to  the 
value  specified  by  the  typeface  posture  indicator.  This  information 
is  used  to  indicate  a  preference  for  one  posture  over  others  when  a 
typeface  is  selected  during  "font  substitution"  or  when  a  graphical 
"font"  is  not  completely  specified  in  a  typographic  sense.  The 
following  posture  values  (from  ISO/DIS  9541)  are  defined: 

upright 

oblique 

back  slanted  oblique 
italic 

back  slanted  italic 

If  the  typeface  posture  indicator  is  not  one  of  the  defined  values, 
then  the  default  value,  upright,  shall  be  used. 


Select  T  peface  Posture 


Relationahio _ tS — particular — atandagrfa  t 


1)  CGM  Fxinctional  Spaclflcation  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

A  functional  description  of  the  Select  Typeface  Posture  escape 
parameters  is : 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 

typeface  posture  indicator (upright,  oblique,  back  slanted 
oblique,  italic,  back  slanted  italic)  (E) 


Items  for  Data  Record: 

typeface  posture  indicator 

The  following  typeface  posture  indicator  values  are  defined: 

1 :  upright 
2 :  oblique 

3 :  back  slanted  oblique 
4 :  italic 

5 :  back  slanted  italic 
Data  Record  Description: 

The  parameter  defines  the  desired  typeface  posture. 
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2)  CGH  Encodings  (reference  ISO  8632  COM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  seG[uential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items), 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 


Select  Typeface  Posture 

3)  6KS  runctional  Sp«ci£icxtlon  (reference  ISO  7942  GXS 
Functional  Description) 

This  escape  is  applicable  at  GKS  level  Oa  and  above.  A  functional 
description  of  its  parameters  is  given  below: 

Nana  Valuaa  Data  Type 

escape  function  identifier  as  assigned  N 

input  data  record: 

typeface  posture  indicator  Note  1  E 

Note  1.  Typeface  posture  indicator  is  one  of:  (upright,  oblique, 
baclc  slanted  oblique,  italic,  back  slanted  italic) 

output  data  record: 
none 


Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  in  one  of  the 
states  GKOP,lfSOP,  WSAC,  or  SGOP 

4)  GKS  FORTRAN  language  binding  (reference  ISO/IEC  8651->1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  subclause  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (TFPOS) 

Input  Parameters : 

INTEGER  TFPOS  typeface  posture  indicator  (upright, 

oblique,  back  slanted  oblique,  italic, 
back  slanted  italic) 

Output  Parameters : 

NONE 


The  following  mnemonic  FORTRAN  names  emd  their  values  for  GKS 
ENUMERATION  type  values  are  added  to  the  list  in  the  GKS 


FORTRAN  binding: 

typeface  posture  upright, 

italic, 

INTEGER  GTFUP, 

GTFITL, 

PARAMETER  (GTFUP  -1, 

GTFITL-4, 


oblique,  back  slanted  oblique, 

back  slanted  italic 
GTFOBL,  GTFBSO, 

GTFBSI 

GTFOBL  -2,  GTFBSO-3, 

GTFBSI -5) 
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b)  The  following  pareuneters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  subclause  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Parameters  used  by  the  Pack  Data  Record  function  for  the  Input  Data 
Record : 

INTEGER  IL  1 

INTEGER  IA(  1  )  posture  Indicator 

INTEGER  RL  0 

INTEGER  SL  0 

The  Unpack  Data  Record  function  la  not  required  by  this  escape. 

5)  Pascal  language  binding  (reference:  ISO/IEC  8651-2,  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  Is  proposed  for  the  procedure 
"GESCAPE"  as  defined  In  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "I"  will  be  replaced  with  the  actual 
ESCAPE  Identifier  at  registration) : 

GEscapeTypefacePostureType  -  (GVEscapeUprlght,  GVEscapeObllque, 

GVEs  capeBackS Ian t  edOb 1 Iqu e , 
GVEscape Italic, 
GVEscapeBackSlantedItallc) ; 


GREscapeDataIn  RECORD 

CASE  EscapelD  :  GTEscapeDataTag  of 
1:  ( 

TextPosture  : GEscapeTypefacePostureType) ; 

End; 


GREscapeDataOut  ■  RECORD 

CASE  Escapeld  ;  GTEscapeDataTag  of 
1:  ()  ;  (*Null  Record  *) 

END; 
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6)  61CS  Ada  languag*  binding  (reference  ISO/IEC  8651-3,  GKS 
Language  Bindings;  Part  3: Ada) 

Registered  ESCAPE ' s  are  in  a  library  package  nruned  GKS_ESCAPE .  GKS 
Ada  provides  a  data  type  package,  (aKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SELECT_TYPEFACE__POSTURE"  form  (as 
defined  in  subclause  4.1  of  the  GKS  Ada  language  binding)  of  the 
ESCAPE  is: 


— Escape  function  for  typeface  posture. 

— Data  type  ESCAPE  ID  is  defined  in  package  GKS_ESCAPE. 
--Other  data  types  are  defined  in  package  GKS-TYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package  GKS_ESCAP£  is 

type  TYPEFACE  POSTURE  INDICATORJTYPE  is  (UPRIGHT,  OBLIQUE, 
BACK__SLANTED_OBLIQUE,  ITALIC,  BAC^C  SLATED  ITALIC)  ; 
type  TYPEFACE  POSTURE  DATA__RECORD  is"  ■“ 

TYPEFACE  POSTURE_INDICATOR  VALUE  :  in 

TYP^ACE_POSTURE_IND  ICATOR_TYPE  ; 

procedure  SELECT_TYPEFACE_POSTURE 

(TYEEFACE_POSTURE_INDICATOR_VALUE  :  in 

TYPEFACE“pOSTURE  INDICATOR  TYPE) ; 


— more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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Proposal  Numbor: 


Dato  of  Presentation:  I  18  July  1988 


Sponsorin 


Class  ot  Graphical  Item:  I  ESCAPE 


Specific  Escape  I  Function  Identifier:  I  Select  Typeface  Structure 


Description 


Select  Typeface  Structure  selects  a  desired  typeface  structure.  This  information  is  used  to  indicate  a  preference 
for  one  structure  over  others  when  a  typeface  is  selected  during  font  substitution*  or  when  a  graphical  font* 
is  not  completeiy  specified  in  a  typographic  sense.  See  attached  sheet  for  additional  details. 


Additional  Comments 


This  escape  is  intended  for  interim  use,  pending  the  revision  of  the  text  model  in  computer  graphics  standards 
based  upon  the  developing  ISO  font  architecture  (DP  9541). 


_  _ Justification  for  Inclusion 


Extensions  to  the  text  model  in  computer  graphics  standards  are  urgently  needed  if  such  standards  are  to  be 
usable  in  office  systems  and  graphic  arts  applications.  Many  proprietary  graphics  systems  currently  use  a 
typographic  text  modal  that  includes  a  structure  attribute.  This  escape  allows  the  structure  of  the  strokes  of  the 
shapes  of  the  glyphs  in  a  typeface  to  be  selected  for  font  substitution  or  selection  purposes. 


Relationship  to  Standards 


1)  ISO  7942  (GKS)  •  Specifies  a  registered  escape  as  defined  in  5.2. 


2)  ISO  8632  (CGM)  -  Specifies  a  registered  escape  as  defined  in  5.8.1. 

3)  ISO  8651  (GKS  Language  Bindings)  -  Specifies  a  registered  escape. 
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Daaeripfclon; 

Salect:  Typafaca  Siiruc^ura  sets  the  desired  typeface  structure 
to  the  value  specified  by  the  typeface  structure  indicator.  This 
information  is  used  to  Indicate  a  preference  for  one  structure  over 
others  when  a  typeface  is  selected  during  "font  substitution"  or 
when  a  graphical  "font"  is  not  completly  specified  in  a  typographic 
sense.  The  following  structure  values  (from  ISO/DIS  9541)  are 
defined: 

solid 

outline 

inline 

shadow 

patterned 

If  the  typeface  structure  indicator  is  not  one  of  the  defined 
values,  then  the  default  value,  solid,  shall  be  used. 
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Ralationahip  to  particular _ atandarda : 


1)  C6M  Functional  Spacification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Deacription) 

A  functional  description  of  the  Select  Typeface  Structure  escape 
parameters  is : 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 

typeface  structure  indicator  (solid,  outline,  inline, 
shadow,  patterned)  (E) 

Items  for  Data  Record: 

typeface  structure  indicator 

The  following  typeface  structure  indicator  values  are  defined: 

1 :  solid 
2 :  outline 
3 :  inline 
4 :  shadow 
5 :  patterned 

Data  Record  Description: 

The  parameter  defines  the  desired  typeface  structure. 
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2}  CQl  Stncodlngs  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  6KS  Functional  Specification  (reference  ISO  7  942  GKS 
Functional  Description) 

This  escape  is  applicable  at  GKS  level  Oa  and  above.  A  functional 
description  of  its  parameters  is  given  below: 

Maae  Values  Data  Type 

escape  function  identifier  as  assigned  N 

input  data  record: 

typeface  structure  indicator  Note  1  E 

Note  1.  Typeface  structure  indicator  is  one  of:  (solid,  outline, 
inline,  shadow,  patterned) 

output  data  record; 
none 


Errors : 

8  GKS  not  in  proper  state:  GKS  shall  he  in  one  of  the 
states  GKOP,  MSOP,  WSAC,  or  SGOP 
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4)  GKS  rORTItAM  language  binding  (reference  ISO/IEC  8651-1,  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  Is  proposed  for  the  "GEpqrs"  form 
(as  defined  In  subclause  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (TFSTRC) 

Input  Parameters : 

INTEGER  TFSTRC  typeface  stiructure  Indicator  (solid, 

outline.  Inline,  shadow,  patterned) 

Output  Parameters : 

NONE 


The  following  mnemonic  FORTRAN  names  and  their  values  for  GKS 
ENUMERATION  type  values  are  added  to  the  list  in  the  GKS 
FORTRAN  binding: 

typeface  structure  solid,  outline,  inline, 

shadow,  patterned 

INTEGER  GTFSOL,  GTFOTL,  GTFINL, 

GTFSHD,  GTFPAT 

PARAMETER  (GTFSOL  -1,  GTFOOTL  -2,  GTFINL-3, 

GTFSHD-4 ,  GTFP AT-5 ) 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Parameters  used  by  the  Pack  Data  Record  function  for  the  Input  Data 
Record: 

INTEGER  IL  1 

INTEGER  lA  (1)  typeface  structure  indicator 

INTEGER  RL  0 
INTEGER  SL  0 

The  Unpack  Data  Record  function  is  not  required  by  this  escape . 
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5)  Pascal  language  binding  (reference:  ISO/IEC  8651-2  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GESCAPE”  as  defined  in  subclause  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "I"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 

GEscapeTypefaceStructureType  - 

(GVEscapeSolid,  GVEscapeOutline, 
GVEscapelnline^  GVEscapeShadow, 
GVEscapePatterned) ; 

GREscapeOataIn  «  RECORD 

CASE  EscapelD  :  (H'EscapeDataTag  of 
1:  ( 

UOOOl  TypefaceWeight 

: GEscapeTypefaceStructureType) ; 

End; 

GREscapeOataOut  »  RECORD 

CASE  Escape Id  :  GTEscapeDataTag  of 
1:  ()  ;  (*Null  Record  *) 

END; 
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6}  62CS  Ada  languaga  binding  (reference  ZSO/IEC  8651-3/  GKS 
Language  Bindings;  Part 3: Ada) 

Registered  ESCAPE'S  are  in  a  library  package  named  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  package/  GKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SELECT_TYPErACE_STRUCTORE"  form  (as 
defined  in  subclause  4.1  of  the  GKS  Ada  language  binding)  of  the 
ESCAPE  is: 


— Escape  function  for  typeface  structure. 

— Data  type  ESCAPE  ID  is  defined  in  package  GXS_ESCAPE . 
— Other  data  types  are  defined  in  package  GKS-TYPES. 


with  GKS__TYPES; 
use  GKSJTYPES; 
package  GKS_ESCAPE  is 

type  TYPEFACE  STRUCTURE_INDICATOR  TYPE  is  (SOLID/  OUTLINE, 
INLINE,  SHADOW,  PATTERNED) ;  *“ 

type  TYPEFACE  STRUCTURE_DATA_RECORD  is 

TYPEFACE  STOUCTURE  INDICATOR  VALUE  :in 

~  ”  typefm:e_structure_indicator_type; 

procedure  SELECT_TYPEFACE_STRUCTURE 

(TYPEFACE  STRUCTURE_INDICAT0R_VALUE  :  in 

TYPEFACE  STRUCTURE  INDICATOR  TYPE) ; 


— more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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SDonsorln 


Class  of  Graohleal  Itam:  I FSCAPE 


Spacific  Escapa  I  Function  Idantiflar: 


face  Scores 


Description 


Select  Typeface  Scores  selects  the  desired  typefaca  scores.  It  allows  selection  of  right  scores  (underscore  in 
lefMo-right  writing  mode  (OIS  9541)  or  RIGHT  Text  Path  (computer  graphics  standards)),  left  scores 
(overscore  in  left-to>right  writing  mode  (OIS  9541)  or  RIGHT  Text  Path  (computer  graphics  standards)),  and 
through  scores  (scores  drawn  through  the  cantra  of  glyphs)  This  information  is  used  to  indicate  a  preference  for 
the  [resence  of  scores  when  a  typefaca  is  selected  during  *ront  substitution*  or  when  a  graphical  font*  is  not 
completely  specified  in  a  typographic  sense.  See  attached  sheets  for  additional  details. 


Additional  Comments 


This  escape  is  intended  for  interim  use,  pending  the  revision  of  the  text  model  in  computer  graphics  standards 
based  upon  the  developing  ISO  font  architecture  (OIS  9541). 


_  Justification  tor  Inclusion 


Extensions  to  the  text  model  in  computer  graphics  standards  are  urgently  needed  if  such  standards  are  to  be 
usable  in  office  systems  and  graphic  arts  applications.  Most  proprietary  graphics  systems  cumently  use  a 
typographic  text  model  that  allows  scoring  as  one  attribute.  Examples  of  such  scores  are  underscores  (or 
underline),  through  scores,  and  overscores.  This  escape  allows  presence  of  scores  in  a  typeface  to  be  selected 
for  font  substitution  or  selection  purposes. 


_ _ _ Relationship  to  Standards 


1)  ISO  7942  (GKS)  -  Specifies  a  registered  escape  as  defined  in  5.2. 

2)  ISO  8632  (CGM)  •  Specifies  a  registered  escape  as  defined  in  5.8.1. 

3)  ISO  8651  (GKS  Language  Bindings)  -  Specifies  a  registered  escape. 
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Paaeripfeion: 

Salacb  Typafaca  Scoxaa  selects  one  of  more  typeface  scores  as 
specified  by  the  values  of  right  score  indicator,  left  score 
indicator,  and  through  score  indicator.  This  information  is  used  to 
indicate  a  preference  for  the  presence  of  scores  when  a  typeface  is 
selected  during  "font  substitution"  or  when  a  graphical  "font"  is 
not  completly  specified  in  a  typographic  sense.  The  following  score 
indicators  (from  ISO/OIS  9541)  are  supported: 

right  score  indicator  (an  underscore  in  left-to-right  writing 
mode) 

left  score  indicator  (an  overscore  in  left-to  right  writing 
mode ) 

through  score  indicator  (a  score  located  through  the  "centre" 
of  the  glyphs) 

The  allowable  values  for  each  score  indicator  are: 

off  :  the  score  is  absent 
on  :  the  score  is  present 

If  any  score  indicator  is  not  one  of  the  defined  values,  then  the 
default  value,  off,  shall  be  used. 
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Rfliatignahip _ ts _ particular  atandarrt^- 


1)  COM  Functional  Specification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

A  functional  description  of  the  Select  Typeface  Scores  escape 
parameters  is: 

Parameters: 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 

right  score  indicator  (off,  on)  (E) 
left  score  indicator  (off,  on)  (E) 
through  score  indicator  (off,  on)  (E) 


Items  for  Data  Record: 

right  score  indicator 
left  score  indicator 
through  score  indicator 

The  following  values  for  each  score  indicator  are  defined: 

0 :  off 
1 :  on 

Data  Record  Description: 

The  parameter  defines  the  desired  typeface  scores. 
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2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,Z,^) 

All  encodings  will  be  handled  in  the  sane  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items), 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  6KS  runctional  Specificatiion  Treference  ISO  7  942  GKS 
Functional  Description) 

This  escape  is  applicable  at  GKS  level  Oa  and  above.  A  functional 
description  of  its  parameters  is  given  below: 


Name  Values  Data  Type 

escape  function  identifier  as  assigned  N 

input  data  record: 

right  score  indicator  (off,  on)  E 

left  score  indicator  (off,  on)  E 

through  score  indicator (off,  on)  E 


output  data  record: 
none 


Errors : 

8  GKS  not  In  proper  state:  GKS  shall  be  in  one  of  the 
states  GKOP,  aSOP,  WSAC,  or  SGOP 

4)  GKS  FORTRAN  language  binding  (reference  ISO/IEC  8651-1,  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as.  defined  in  subclause  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (TFSCOR) 

Input  Parameters : 

INTEGER  TFRSCR  right  score  indicator  (off,  on) 

INTEGER  TFLSCR  left  score  indicator  (off,  on) 

INTEGER  TFTSCR  through  score  indicator  (off,  on) 

Output  Parameters : 

NONE 


The  following  mnemonic  FORTRAN  names  and  their  values  for  GKS 
ENUMERATION  type  values  are  added  to  the  list  in  the  GKS 
FORTRAN  binding: 

typeface  score  indicator  on,  off 

INTEGER  GTFSON,  GTFSOF 

PARAMETER  (GTFSON-0,  GTFSOF- 1) 
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b)  The  following  pareuneters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  subclause  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Parameters  used  by  the  Pack  Data  Record  function  for  the  Input  Data 
Record: 

INTEGER  IL 
INTEGER  lA  (1) 

INTEGER  lA  (2) 

INTEGER  lA  (3) 

INTEGER  RL  0 
INTEGER  SL  0 

The  Unpack  Data  Record  function  is  not  required  by  this  escape. 


3 

right  score  indicator  (off,  on) 
left  score  indicator  (off,  on) 
through  score  indicator  (off,  on) 
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5)  Pascal  language  binding  (reference:  ISO/IEC  8651-2,  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  Is  proposed  for  the  procedure 
"GESCAPE"  as  defined  In  subclause  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 

GEscapeTypefaceScoreType  -  (GVEscapeScoreOff , 

(TVEscapeScoreOn) ; 


GREscapeDataIn  -  RECORD 

CASE  EscapelD  :  GTEscapeDataTag  of 
1:  ( 

00001  RightScoreIndicator 

: GEscapeTypefaceScoreType) ; 
00001  LeftScorelndicator 

: GEscapeTypefaceScoreType) ; 
OOOOl  ThroughScore Indicator 
: GEscapeTypefaceScoreType) / 

End; 

GREscapeDataOut  ■  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 
1:  0  ;  (*Null  Record  *) 

END; 
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6)  6KS  Ada  language  binding  (reference  ISO/IEC  8651-3,  GKS 
Language  Bindings;  Part  3: Ada) 

Registered  ESCAPE'S  are  in  a  library  package  named  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  package,  GKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SELECT_TYPEFACE_SCORES"  form  (as 
defined  in  s\ibclause  4.1  of  the  GKS  Ada  language  binding)  of  the 
ESCAPE  is: 


— Escape  function  for  typeface  scores. 

— Data  type  ESCAPE  ID  is  defined  in  package  GKS_ESCAPE. 
— Other  data  types  are  defined  in  package  GKS-TYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package  GKS_ESCAPE  is 

type  TYPEFACE  SCORE  INDICATOR  TYPE  is  (OFF,  ON) ; 
type  TYPEFACE3C0RE“dATA_REC0Sd  is 
record  ~ 

RIGHT_SCORE_INDICATORj;ALDE  :  in 

“  “  TYPEFACE  SCORE  INDICATOR  TYPE; 

IiEFT__SCORE_INDICATOR_VALtfe  T  in  “ 

“  TYPEFACE  SCORE  INDICATOR  TYPE; 
THROUGH_SCORE_INDICATOR_VALUE  ~  :  in  ” 

TYPEFACE_SCORE_INDICATOR  TYPE; 
end  record;  ” 

procedure  SELECT_TYPEFACE_SCORES 

(TYPEFACE_SCORE_RECORD  :  in  TYPEFACE  SCORE  DATA  RECORD) ; 


— more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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Oat*  of  Pr*a*ntatlon:  I  18  July  1988 


Soonsorlna  Authority:  I  ANSI 


ESCAPE 


Specific  Escape  I  Function  Identifier:  |  Select  Typeface  Weiqht 


Description 


Select  Typeface  Weight  selects  a  desired  typeface  weight  This  information  is  used  to  indicate  a  preference  for 
one  weight  over  others  when  a  typeface  is  selected  during  ’font  substitution*  or  when  a  graphical  ’font’  is  not 
completely  specified  In  a  typographic  sense.  See  attached  sheet  for  additional  details. 


Additional  Comments 


This  escape  is  intended  for  interim  use,  pending  the  revision  of  the  text  model  in  computer  graphics  standards 
based  upon  the  developing  ISO  font  architecture  (DP  9541). 


_ _ Justification  for  Inclusion 


Extensions  to  the  text  model  in  computer  graphics  standards  are  urgently  needed  if  such  standards  are  to  be 
usable  in  office  systems  and  graphic  arts  applications.  Most  proprietary  graphics  systems  cunently  use  a 
typographic  text  model  that  includes  a  weight  attribute.  This  escape  allows  the  weighte  of  a  typeface  to  be 
selected  for  font  substitution  or  selection  purposes. 


_ _ Relationship  to  Standards 


1)  ISO  7942  (GKS)  •  Specifies  a  registered  escape  as  defined  in  5.2. 

2)  ISO  8632  (COM)  -  Specifies  a  registered  escape  as  defined  in  5.8. 1. 

3)  ISO  8651  (GKS  Language  Bindings)  ■  Specifies  a  registered  escape. 
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Pflaggiptigoi. 

S«l«c^  Typ*fae«  W«ighfc  sets  the  desired  typeface  weight  to  the 
value  specified  by  the  typeface  weight  indicator.  This  information 
is  used  to  indicate  a  preference  for  one  weight  over  others  when  a 
typeface  is  selected  during  "font  substitution"  or  when  a  graphical 
"font"  is  not  completly  specified  in  a  typographic  sense.  The 
following  weight  values  (from  ISO/DIS  9541)  are  defined: 

ultra  light 
extra  light 
light 

semi  light 
medium 
semi  bold 
bold 

extra  bold 
ultra  bold 

If  the  typeface  weight  indicator  is  not  one  of  the  defined  values, 
then  the  default  value,  medium,  shall  be  used. 
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Relationahip  to _ particular _ atandarda ; 


1)  CGH  Functional  Specification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

A  functional  description  of  the  Select  Typeface  Posture  escape 
parcuneters  is : 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 

typeface  weight  indicator  (ultra  light,  extra  light, 
light,  serai  light,  medium,  semi  bold,  bold,  extra  bold, 
ultra  bold)  (E) 


Items  for  Data  Record: 

typeface  weight  indicator 

The  following  typeface  weight  indicator  values  are  defined: 

1 :  ultra  light 
2 :  extra  light 
3 :  light 
4 :  semi  light 
5 :  medium 
6:  semi  bold 
7:  bold 
8:  extra  bold 
9:  ultra  bold 

Data  Record  Description: 

The  parameter  defines  the  desired  typeface  weight. 
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2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding-  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  GKS  Functional  Specification  (reference  ISO  7942  GKS 
Functional  Description) 

This  escape  is  applicable  at  GKS  level  Oa  and  above.  A  functional 
description  of  its  parauneters  is  given  below: 

Name  Values  Data  Type 

escape  function  identifier  as  assigned  N 

input  data  record: 

typeface  weight  indicator  Note  1  E 

Note  1.  Typeface  weight  indicator  is  one  of:  (ultra  light,  extra 

light,  light,  semi  light,  medium,  semi  bold,  bold,  extra  bold, 
ultra  bold) 

output  data  record: 
none 


Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  in  one  of  the 
states  GKOP,»SOP,  WSAC,  or  SGOP 

4)  GXS  FORTRAN  language  binding  (reference  ISO/IEC  8651-1,  GKS 
Language  Bindings ;  Part  1 :  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  subclause  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (TFWGHT) 

Input  Parameters : 

INTEGER  TFWGHT  typeface  weight  indicator  (ultra  light, 

extra  light,  light,  semi  light,  medium, 
semi  bold,  bold,  extra  bold,  ultra 
bold) 

Output  Parameters : 

NONE 
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The  following  mnemonic  FORTRAN  names  and  their  values  for  GKS 
ENUMERATION  type  values  are  added  to  the  list  in  the  GKS 
FORTRAN  binding: 


typeface  weight 

ultra  light. 

extra  light 

light , 

semi  light. 

medium. 

semi  bold. 

bold, 

ultra  bold 

extra  bold. 

INTEGER 

GTFUL, 

GTFEL, 

GTFLIT, 

GTFSL, 

GTFMED, 

GIF SB, 

GTFBLD, 

GTFUB 

GTFEB, 

PARAMETER 

(GTFUL-1, 

GTFEL-2, 

GTFLIT-3, 

GTFSL-4, 

GTFMED-5, 

GTFSB-6, 

GTFBLD-7, 

GTFUB-9) 

GTFEB-8, 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  subclause  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Parameters  used  by  the  Pack  Data  Record  function  for  the  Input  Data 
Record: 

INTEGER  IL  1 

INTEGER  lA  (1)  typeface  weight  indicator 

INTEGER  RL  0 
INTEGER  SL  0 


The  Unpack  Data  Record  function  is  not  required  by  this  escape . 
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5)  Pascal  language  binding  (reference:  ISO/IEC  8651-2,  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GESCAPE"  as  defined  in  subclause  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 

GEscapeTypefaceWeightType  -  (GVEscapeUltraLight, 

GVEscapeExtraLight , 
GVEscapeLight , 

GVEscapeSemiLight , 

GVEscapeMedium, 

GVEscapeSemiBold, 

GVEscapeBold, 

GVEscapeExtraBold, 
GVEscapeGltraBold) ; 

GREscapeOataIn  *  RECORD 

CASE  Escape ID  :  GTEscapeDataTag  of 
1:  ( 

UOOOl  TypefaceWeight 

: GEscapeTypefaceWeightType) ; 

End; 

GREscapeDataOut  *■  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 
1:  0  ;  (*Null  Record  *) 

END; 
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6)  GKS  Ada  language  binding  (reference  ISO/IEC  8651-3,  GKS 
Language  Bindings;  Part  3: Ada) 

Registered  ESCAPE’S  are  in  a  library  package  named  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  package,  GKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SELECT_TYPEFACE_WEIGHT"  form  (as 
defined  in  subclause  4.1  of  the  GKS  Ada  language  binding)  of  the 
ESCAPE  is: 


— Escape  function  for  typeface  weight. 

— Data  type  ESCAPE  ID  is  defined  in  package  GKS^ESCAPE. 
— Other  data  types  are  defined  in  package  GKS-TYPES. 


with  GKS_TYPES/ 
use  GKS_TYPES; 
package  GKS_ESCAPE  is 

type  TYPEFACE_WEIGHT_INDICATOR_TYPE  is  (ULTRA  LIGHT,  EXTRA_LIGHT, 
LIGHT,  SEMI__LIGHT,  MEDIUM,  ^MI  BOLD,  BOLD,” EXTRA  BOLD, 

ULTRA  BOLD) ; 

type  TyPEFACE_WEIGHT  DATA_RECORD  is 

TYPEFACE_WEIGHT_INDICAT0R_VALUE  :  in 

”  “  TYPEFACE_WEIGHT_INDICAT0R_TYPE; 

procedure  SELECT_TYPEFACE_WEIGHT 

(TYPEFACE_WEIGHT_INDICATOR_VALUE  :  in 

TYPEFACE_WEIGHT_INDICATOR  TYPE) ; 


— more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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Proposal  Number:!  53 


Date  of  Presentation:  I  9  September  1988 


Sponsorln 


Class  of  Graphical  Item:  I  ESCAPE 


Specific  Escape  I  Function  Identifier:  I  Set  Fully  Justified  Text 


_ Description 


This  escape  function  sets  a  value  for  the  fully  justified  text  This  value  may  be  either  on,  indicating  that 
Restricted  Text  (and  associated  Append  Text)  is  drawn  in  a  fully  justified  style,  or  off,  indicating  that 
Restricted  Text  is  not  drawn  in  a  fully  justified  style.  This  attribute  has  no  affect  on  the  drawing  of  Text 
primitives,  and  does  not  apply  to  standards  that  do  not  contain  a  Restricted  Text  Primitive.  See  attached  sheet 
for  additional  details. 


_ Additional  Comments 


This  escape  is  intended  for  interim  use.  pending  the  revision  of  the  text  model  in  computer  graphics  standards 
based  upon  the  developing  ISO  font  architecture  (OP  9541). 


_ _  _ _ Justification  for  Inclusion 


Extensions  to  the  text  model  in  computer  graphics  standards  are  urgently  needed  if  such  standards  are  to  be 
usable  for  most  applications.  Most  proprietary  graphics  systems  supporting  typographic  quality  text  allow  fully 
justified  text  Such  text  is  drawn  by  the  target  system  by  varying  the  spacing  between  words  and  characters  in 
a  text  string  to  insure  that  the  string  starts  at  the  beginning  of  a  restricted  region,  ends  at  the  end  of  the  region, 
and  has  a  pleasing  appearance.  The  Restricted  Text  primitive  in  the  existing  graphics  standards  partially  meets 
this  goal,  but  its  semantics  allows  the  target  system  to  adjust  text  by  many  different  means  to  meet  this 
restriction.  This  escape  requires  that  the  tsxt  be  fit  by  adjusting  only  the  Character  Spacing  where  this  is 
possible.  Equivalent  effects  cannot  bo  achieved  with  typographic  fonts  by  directly  adjusting  Character  Expansion 
Factor  and  Character  Spacing,  especially  where  font  substitution  may  occur.  Based  on  ‘minimality*,  it  was 
decided  to  simply  add  an  ‘attribute*  to  Restricted  Text  and  Append  Text  to  affect  this  restriction  rather  than 
adding  a  seoarate  ‘Justified  Text*  primitive. 


Relationship  to  Standards 


1)  ISO  7942  (GKS)  •  Not  applicable. 


2)  ISO  8632  (CGM)  •  Specifies  a  registered  escape  as  defined  in  5.8.1. 

3)  ISO  8651  (GKS  Language  Bindings)  -  Not  applicable. 
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Pflacriptiani. 

S«t  Fully  Jus'ti£iad  Taxt  sets  a  current  fully  justified  text 
value  to  the  value  specified  by  the  fully  justified  text  indicator. 
This  establishes  whether  Restricted  Text  (and  Append  Text 
associated  with  Restricted  Text)  are  drawn  in  a  fully  justified 
style  as  defined  below.  This  escape  is  applicable  only  to  standards 
that  include  a  Restricted  Text  primitive. 

Fully  Justified  text  is  defined  by  these  rules : 

1)  As  with  Restricted  Text,  fully  justified  text  is  constrained  to 
be  contained  within  the  parallelogrcun  defined  with  the  Restricted 
Text  primitive. 

2)  In  fitting  the  text  within  this  parallelogram,  the  values  of 
Character  Height,  Character  Expansion  Factor,  Text  Precision,  and 
TextFont  Index  may  not  be  adjusted.  Only  the  Character  Spacing  may 
be  adjusted. 

3)  The  text  is  drawn  in  such  a  way  that  the  characters  drawn  appear 
to  "fill"  the  parallelogram  along  the  text  path,  with  the  first  and 
last  characters  drawn  touching  the  sides  of  the  parallelogram.  In 
case  the  text  cannot  be  fit  within  the  parallelogram  by  adjusting 
only  the  Character  Spacing,  then  the  text  will  be  drawn  using  the 
rules  for  Restricted  Text. 

4)  The  manner  in  which  Character  Spacing  is  adjusted  when 
implementing  fully  justified  text  is  implementation  dependent.  It 
is  suggested,  however,  that  the  excess  space  (the  length  in  the 
Restricted  Text  primitive  less  the  sum  of  the  lengths  of  all  the 
individual  characters  in  the  string)  be  divided  between 
inter-character  and  inter-word  spacing  by  dividing  1/3  of  the 
excess  space  equally  among  all  inter-character  spaces  and  dividing 
2/3  of  the  excess  space  equally  among  all  inter-word  spaces  in  the 
string.  This  is  the  most  common  rule  used  in  typographic  practice. 

The  following  fully  justified  text  indicator  values  are  defined: 

Off -.fully  justified  text  is  set  to  Off,  indicating  that 
Restricted  Text  and  associated  Append  Text  is  not  drawn  in  a 
fully  justified  style. 

On:  fully  justified  text  is  set  to  On,  indicating  that 
Restricted  Text  and  associated  Append  Text  is  drawn  in  a  fully 
justified  style. 

If  the  fully  justified  text  indicator  value  is  not  one  of  the 
defined  values,  then  the  default  value.  Off  shall  be  used. 
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Raiationahip  to _ particttlag — ataodarda ; 

1)  CGM  runctional  Spaciflcation  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

A  functional  description  of  the  Set  Fully  Justified  Text  escape 
pareuneters  is : 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 

fully  justified  text  indicator (Off ,  On)  (E) 


Items  for  Data  Record: 

fully  justified  text  indicator 

The  following  values  of  fully  justified  text  indicator  are  defined; 

1:  Off 
2 :  On 

Data  Record  Description: 

The  parameter  defines  the  fully  justified  text  indicator. 

2)  CGM  Xncodinga  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items), 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  GXS  Functional  Specification  (reference  ISO  7942  GKS 
Functional  Description) 

This  escape  does  not  apply  to  GXS  since  it  does  not  contain  a 

Restricted  Text  primitive. 

4)  GXS  FORTRAN  language  binding  (reference  ISO/IEC  8651-1,  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

This  escape  does  not  apply  to  GKS  since  it  does  not  contain  a 

Restricted  Text  primitive. 

5)  Pascal  language  binding  (reference:  ISO/IEC  8651-2  GKS 

Language  Bindings;  Part  2:  Pascal) 

This  escape  does  not  apply  to  GKS  since  it  does  not  contain  a 

Restricted  Text  primitive. 

6)  GXS  Ada  language  binding  (reference  ISO/IEC  8651-3,  GKS 
Language  Bindings;  Part  3: Ada) 

This  escape  does  not  apply  to  GKS  since  it  does  not  contain  a 

Restricted  Text  primitive. 
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Proposal  Numbem  54 


Data  of  Prasantatlon:  I  18  Juiv  1988 


Class  of  Graphical  Itam:  I  ESCAPE 


Specific  Escape  I  Function  Identifier:  |  Select  Typeface  Proportionate  Width 


Description 


Select  Typeface  Proportionate  Width  selects  a  desired  typeface  proportionate  width.  This  information  is  used  to 
indicate  a  preference  for  one  proportionate  width  over  others  when  a  typeface  is  seiected  during  ’font 
substitution*  or  when  a  graphical  font*  is  not  compiatly  speciflad  in  a  typographic  sense.  See  attached  sheet  for 
additional  details. 


Additional  Comments 


This  escape  is  intended  for  interim  use,  pending  the  revision  of  the  text  model  in  computer  graphics  standards 
based  upon  the  developing  ISO  font  architecture  (OP  9541). 


_ _ Justification  tor  Inclusion 


Extensions  to  the  text  model  in  computer  graphics  standards  are  urgently  needed  if  such  standards  are  to  be 
usable  in  office  systems  and  graphic  arts  applications.  Many  proprietary  graphics  systems  currently  use  a 
typographic  text  model  that  indudes  a  proportionate  width  attribute.  This  escape  allows  the  proportionate  width 
of  a  typeface  to  be  selected  for  font  substitution  or  selection  purposes.  For  example,  extended  and  condensed 
fonts  are  provided,  where  the  font  designer  specifies  changes  in  character  spacing  to  achieve  the  condensed  or 
extended  appearance.  Although  these  effects  could  be  crudely  approximated  by  varying  the  Character  Spacing 
attribute  of  graphical  text,  such  an  approximation  is  inappropriate  for  systems  that  require  high-quality  text. 


_ Relationship  to  Standards 


1 )  ISO  7942  (GKS)  -  Specifies  a  registered  escape  as  defined  in  5.2. 


2)  ISO  8632  (COM)  -  Specifies  a  registered  escape  as  defined  in  5.8.1. 

3)  ISO  8651  (GKS  Language  Bindings)  -  Specifies  a  registered  escape. 
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DgacriiPtign;. 

Salact  Typa£aca  Proportionata  Widtli  sets  the  desired  typeface 
proportionate  width  to  the  value  specified  by  the  typeface 
proportionate  width  indicator.  This  information  is  used  to  indicate 
a  preference  for  one  proportionate  width  over  others  when  a 
typeface  is  selected  during  "font  substitution"  or  when  a  graphical 
"font"  is  not  completly  specified  in  a  typographic  sense.  The 
following  proportionate  width  values  (from  ISO/DIS  9541)  are 
defined: 

ultra  condensed  (highest  ratio  of  glyph  height  to  width) 

extra  condensed 

condensed 

semi  condensed 

medium 

semi  expanded 
expanded 
extra  expanded 

ultra  expanded  (lowest  ratio  of  glyph  height  to  width) 

If  the  typeface  proportionate  width  indicator  is  not  one  of  the 
defined  values,  then  the  default  value,  medium,  shall  be  used. 
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Relationahip  to _ particular _ fltandarria; 


1)  CGM  Functional  Spacification  (reference  ISO  8632  CGM; 

Part  1;  Functional  Description) 

A  functional  description  of  the  Select  Typeface  Proportionate  Width 
escape  parauneters  is : 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 


data  record  (D) : 

typeface  proportionate  width  indicator  (ultra  condensed, 
extra  condensed,  condensed,  semi  condensed,  medium,  semi 
expanded,  expanded,  extra  expanded,  ultra  expanded)  (E) 


Items  for  Data  Record: 

typeface  proportionate  width  indicator 

The  following  typeface  proportionate  width  indicator  values  are 
defined: 

1 :  ultra  condensed 
2 :  extra  condensed 
3 :  condensed 
4 :  semi  condensed 
S :  medium 
6:  semi  expanded 
7 :  expanded 
8 :  extra  expanded 
9:  ultra  expanded 

Data  Record  Description: 

The  parameter  defines  the  desired  typeface  proportionate  width. 
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2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2^3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  6Kb  runctional  Spaciflcation  (reference  ISO  7942  GKS 
Functional  Description) 

This  escape  is  applicable  at  GKS  level  Oa  and  above.  A  functional 
description  of  its  parameters  is  given  below: 

Name  Values  Data  Type 

escape  function  identifier  as  assigned  N 

input  data  record: 

typeface  proportionate  Note  1  E 

width  indicator 

Mote  1.  Typeface  proportionate  width  indicator  is  one  of:  (ultra 
condensed,  extra  condensed,  condensed,  semi  condensed,  medium,  semi 
expanded,  expanded,  extra  expanded,  ultra  expanded) 

output  data  record: 
none 


Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  either  in  one  of  the 
states  GKOP^ffSOP,  ffSAC,  or  SGOP 

4)  GKS  FORTRAN  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (TFPRWD) 

Input  Parameters : 

INTEGER  TFPRWD  typeface  proportionate  width  indicator 

(ultra  condensed,  extra  condensed, 
condensed,  semi  condensed,  medium,  semi 
expanded,  expanded,  extra  expanded, 
ultra  expanded) 

Output  Parameters : 

NONE 
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The  following  nmemonic  FORTRAN  names  and  their  values  for  GKS 
ENUMERATION  type  values  are  added  to  the  list  in  the  GKS 
FORTRAN  binding; 


typeface  proportionate 
width 


INTEGER 


PARAMETER 


ultra  condensed, 

condensed, 

meditim, 

expamded, 

ultra  expanded 

GTFUC, 

GTFCON, 

GTFMEO, 

GTFEXP, 

GTFUE 

(GTFUC-1, 


extra  condensed, 
semi  condensed, 
semi  expanded, 
extra  expanded, 

GTFEC, 

GTFSC, 

GTFSE, 

GTFEE, 

GTFEC-2, 


GTFCON-3, 

GTFMED-5, 

GTFEXP-7, 

GTFGE-9) 


GTFSC-4, 

GTFSE-6, 

GTFEE-a, 


b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  stauidard: 


Parameters  to  the  Pack  and  Unpack  Data  Record  functions: 
INTEGER  IL  1 

INTEGER  IA(  1  )  proportionate  width  indicator 

INTEGER  RL  0 
INTEGER  SL  0 
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5)  Pascal  language  binding  (reference:  ISO  OIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GESCAPE"  as  defined  in  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 

GEs  capeType  f aceP  roport ionat eWidthType  - 

((^scapeUltraCc  iidensed, 
GVEscapeExtraCondensed, 
GVEscapeCondensedr 
(oVEscapeSemiCondensed, 

GVEscapeMediuin, 

GVEscapeSemiExpanded , 

GVEscapeExpandedr 
GVEscapeExt  r aExpanded , 
GVEscapeCltraExpanded) ; 

GREscapeOataIn  >  RECORD 

CASE  EscapelD  :  CsTEscapeDataTag  cf 
1:  ( 

UOOOl  TypeFaceP roport ionat eWidth 
:GEscapeTypefaceProportionateWidthType)  ; 

End; 

GREscapeOataOut  ■■  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 
1:  0  ;  (*Null' Record  *) 

END; 


273 


Si.iect  Typeface  Propoitionale  Width 

6)  acs  Ada  language  binding  (reference  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part3:Ada) 

Registered  ESCAPE'S  are  in  a  library  package  named  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  package,  GKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SELECT_TYPEFAC:e_PROPORTIONATE_WIDTH" 
form  (as  defined  in  Paragraph  4.1  of  the  GKS  Ada  language  binding) 
of  the  ESCAPE  is: 


—Escape  ftinctlon  for  typeface  proportionate  width. 

— Data  type  ESCAPE  ID  is  defined  in  package  GKS__ESCAPE. 
—Other  data  types  are  defined  in  package  GKS-TYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package  GKS_ESCAPE  is 

type  TYPEFACE  PROPORTIONATE_WIDTH_INDICATOR  TYPE  is  ( 

OLTRA_CONDENSED,  EXTRA_CONDENSED,  CONDEN^D,  SEMI_CONDENSED , 
MEDIUM,  SEMI__EXPANDED,  EXPANDED,  EXTRA_EXP ANDED ,  ULTRA__EXPANDED 
) ; 

type  TYPEFACE  PROPORTIONATE  WIDTH__DATA  RECORD  is 

TYPEFACE  P'ROPORTIONATE_wiDTH  INDICATOR  VALUE  :in 

typeface_proportionate__widtrJ&id  ICAT0R_T^E  ; 

procedure  SELECT_TYPEFACE_PROPORTIONATE_WIDTH 

(ESCAPE_IDENTIFIER  :in  ESCAPE_ID: 

TYPEFACE_PROPORTIONATE_WIDTH  INDICATOR  VALUE  :  in 
TYPEFACE  PROPORTIONATE  WIDTH“iNDICATOR“"tYPE)  ; 


— more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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ProDosal  Number: 


Date  of  Presentation:  I  10  Aoril  1987 


Soonsorln 


Class  of  Graolileal  Item:  I GCP 


GOP  Identifier:  Pel  Arra 


Oescrlptlon 


This  Generalized  Drawing  Primitiva  provides  a  very  flexible  mechanism  (or  describing  raster  (image)  data 
within  computer  graphics  standards.  It  can  be  viewed  as  an  extension  of  the  Call  Array  primitive  to  allow 
aitarnata  encoding  and  compression  schemes.  See  attached  sheets  for  additional  details. 


Additional  Comments 


_ _ Relationship  to  Standards 


1 )  ISO  7942  (GKS)  -  Specifies  a  registered  GOP  as  defined  in  5.3. 

2)  ISO  8632  (CGM)  •  Specifies  a  registered  GOP  as  defined  in  5.6.10. 

3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  GOP.  (See  attached  sheets). 
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Deacgiption;. 

The  Pel  Array  generalized  drawing  primitive  is  an  extended  version 
of  the  Cell  Array  primitive  designed  to  support  the  transfer, 
storage,  and  printing  of  raster  image  data  from  a  variety  of 
sources . 

Parameters : 

3  corner  points  P,Q/  and  R  {3P) 

nx,ny  (n\imber  of  pels  per  line;  number  of  lines)  (21) 
encoding  (one  of:  pac)ced,  run-length,  T.4,  T.6,  LZW)  (E) 
local  colour  precision 

pel  array  colour  specifiers  (nx*ny*local  colour  precision) 

In  the  general  case,  P,Q, R  can  delimit  an  arbitrary  parallelogram. 
P  and  Q  delimit  the  end  points  of  a  diagonal  of  the  parallelogram, 
and  R  defines  a  third  corner. 

In  the  simplest  case,  the  three  corner  points,  P,Q,R,  define  a 
rectangular  area  in  the  coordinate  space.  This  area  is  subdivided 
into  nx*ny  contiguous  rectangles  as  follows .  The  edge  from  P  to  R 
is  subdivided  into  nx  equal  intervals,  and  the  edge  from  R  to  Q  is 
subdivided  into  ny  equal  intervals.  l*he  grid  implied  consists  of 
nx-^ny  identical  pels.  The  colour  list  consists  of  nx*ny  colour 
specifications,  conceptually  an  array  of  dimensions  nx  and  ny 
representing  respectively  the  column  and  row  dimensions.  Array 
element  (1,1)  is  mapped  to  the  pel  at  corner  P,  and  array  element 
(nx,l)  is  mapped  to  pel  at  corner  R.  Array  element  (nx,ny)  is 
mapped  to  the  pel  at  corner  Q.  Hence,  the  colour  elements  are 
mapped  within  rows  running  from  P  to  R,  and  with  the  rows 
incrementing  in  order  from  R  to  Q.  [Note  that  all  four  traditional 
values  of  pel  path  —  0,  90,  180,  and  270  —  as  well  as  both 

traditional  values  of  line  progression  —  90  and  270  —  can  be 
realized  by  varying  the  inter-relationships  among  P,  Q,  and  R] 

The  encoding  parameter  specifies  how  the  pel  array  values  are 
encoded.  This  parameter  allows  an  API  standard  to  pick  up  a  pel 
array  (image)  obtained  from  an  external  device,  such  as  a  scanner, 
and  image  (print)  it  without  having  to  interpret  the  data  in  it. 
Similarly,  it  allows  a  graphical  metafile  or  interface  standard  to 
transfer  such  data  without  having  to  interpret  it.  The  allowable 
values  of  encoding  are: 


Packed  :  No  compression,  but  pack  colour  values  as  tightly  as 
possible,  with  no  unused  bits  except  at  the  end  of  a  row.  The 
colour  values  are  represented  by  rows  of  values,  each  row  starting 
on  a  (16  bit)  word  boundary.  (Note:  This  encoding  is  identical  to 
the  "packed  list"  mode  in  the  binary  binding  of  the  CGM.  It  is  also 
equivalent  to  the  "packed"  mode  of  TIFF,  with  byte  order  restricted 
to  "MM" . 1 
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Run-langth  :  The  colour  list  values  are  represented  by  rows 
broken  into  runs  of  constant  colour;  each  row  starts  on  a  (16  bit) 
word  boundary.  [Note:  This  encoding  is  identical  to  the  "packed 
list"  mode  in  the  binary  binding  of  the  t,i5M.  ] 

T.4  one  dimensional  :  Facsiinile**compatible  CCITT  Group  3, 
exactly  as  specified  in  "Standardization  of  Group  3  facsimile 
apparatus  for  document  transmission"  Recommendation  T.4  Volume  VII, 
Fascicle  VII. 3,  Terminal  Equipment  and  Protocols  for  Telematic 
Services,  The  International  Telegraph  and  Telephone  Consultative 
Committee  (CCITT),  Geneva,  1985,  pages  16  through  21.  All  rows 
must  begin  on  a  byte  boundary.  The  restrictions  in  T.4  for  the 
number  of  pels  per  line  (nx) ,  the  number  of  lines  per  pel  array 
(ny)  ,  and  the  size,  position,  and  orientation  of  an  pel  array 
within  a  picture  do  not  apply.  [Note  that  the  addition  of  fill  bits 
before  EOLs  to  force  them  to  end  on  word  boundaries  is  not  required 
but  is  allowed.] 

T.4  two  dimensional  :  Facsimile-compatible  CCITT  Group  3  two 
dimensional,  exactly  as  specified  in  "Standardization  of  Group  3 
facsimile  apparatus  for  document  transmission"  Recommendation  T.4 
Volume  VII,  Fascicle  VII. 3,  Terminal  Equipment  and  Protocols  for 
Telematic  Services,  The  International  Telegraph  and  Telephone 
Consultative  Committee  (CCITT),  Geneva,  1985,  pages  21  through  20. 
All  rows  must  begin  on  a  byte  boundary.  The  restrictions  in  T.4  for 
the  n\imber  of  pels  per  line  (nx) ,  the  number  of  lines  per  pel  array 
(ny)  ,  and  the  size,  position,  and  orientation  of  an  pel  array 
within  a  picture  do  not  apply.  [Note  that  the  addition  of  fill  bits 
before  EOLs  to  force  them  to  end  on  word  boundarias  is  not  required 
but  is  allowed.] 

T.6  ;  Facsimile-compatible  CCITT  Group  4,  exactly  as  specified  in 
"Facsimile  Coding  Schemes  and  Coding  Control  Functions  for  Group  4 
Facsimile  Apparatus",  Recommendation  T.6,  Volume  VII,  Fascicle 
VII. 3.  Terminal  Equipment  and  Protocols  for  Telematic  Services,  The 
International  Telegraph  and  Telephone  Consultative  Committee 
(CCITT),  Geneva,  1985,  pages  40  through  48.  The  restrictions  in  T.4 
for  the  number  of  pels  per  line  (nx) ,  the  number  of  lines  per  pel 
array  (ny) ,  and  the  size,  position,  and  orientation  of  an  pel  array 
within  a  picture  do  not  apply.  [Note  that  the  addition  of  fill  bits 
before  EOLs  to  force  them  to  end  on  word  boundaries  is  not  required 
but  is  allowed.]  [Note;  This  encoding  is  identical  to  that  of  the 
T.4  two  dimensional  with  the  single  exception  that  the  "K" 
parameter  which  controls  the  number  of  consecutive  two  dimensional 
lines  without  an  intervening  one  dimensional  line  has  the  value 
infinity  rather  than  a  small  integer.] 

LZW  Compression  :  An  adaptive  compression  for  raster  images  as 
defined  in  an  article  by  Terry  A.  Welch,  entitled  "A  Technique  for 
High  Performance  Data  Compression",  IEEE  Computer  ,  vol .  17  no.  6 
(June  1984),  and  called  the  basic  Lempel-Ziv  &  Welch  (LZW) 
algorithm.  [Note:  The  author’s  goal  in  that  article  was  to  describe 
a  hardware-based  compressor  that  could  be  built  into  disk 
controller  or  database  engine,  and  used  on  all  types  of  data.  There 
is  no  specific  discussion  of  raster  images.] 

LZW  is  fully  reversible.  All  information  is  preserved,  but  if  noise 
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or  information  is  removed  from  am  image,  perhaps  by  smoothing  or 
zeroing  some  low-order  bitplanes,  LZW  compresses  images  into  a 
smaller  size.  Thus,  5-bit,  6-bit,  or  7-bit  data  masquerading  as 
8-bit  data  compresses  better  than  true  8-bit  data.  Smooth  images 
also  compress  better  than  noisy  images,  and  simple  images  compress 
better  than  complex  images .  LZW  works  well  on  bilevel  images  too . 

LZW  Encoding 

The  LZW  algorithm  is  based  on  a  translation  tadale,  or  string  table, 
that  maps  strings  of  input  characters  into  codes.  Variable-length 
codes  are  used,  with  a  maximum  code  length  of  12  bits .  This  string 
table  is  different  for  every  pel  array,  and,  remarkcdjly,  does  not 
need  to  be  kept  for  the  decompressor.  The  trick  is  to  make  the 
decompressor  automatically  build  the  same  table  as  is  built  when 
compressing  the  data.  The  following  C-like  pseudocode  describes  the 
coding  scheme: 

InitializeStringTable 0 ; 

WriteCode (ClearCode) ; 

£1  -  the  empty  string 

for  each  character  in  the  pel  array! 

K  *  GetNextOctet 0 ; 

if  il+K  is  the  string  table! 

a  -  fl+K;  /*  string  concatenation*/ 

}else! 

WriteCode  (CodeFromString  (11) )  ; 

AddTableEntry (Q) ; 

a  -  K; 

} 

}/*end  of  for  loop*/ 

WriteCode (CodeFromString (H) )  ; 

WriteCode (Endofinformation) ; 

The  "characters"  that  make  up  LZW  strings  are  octets  of 
uncompressed  pel  array  data.  InitializeStringTable!)  initializes 
the  string  table  to  contain  all  256  possible  single  octet  codes, 
numbered  0  through  255.  WriteCode!)  writes  a  code  to  the  output 
stream.  The  first  code  written  is  a  Clear  code,  which  is  defined  to 
be  code  #256.  £1  represents  the  "prefix"  string.  GetNextOctet!) 
retrieves  the  next  octet  from  the  input  stream.  The  "  +  "  sign 
indicates  string  concatenation. 

AddTableEntry !)  adds  a  table  entry.  Since  InitializeStringTable  has 
already  added  256  entries  to  the  table,  and  since  entry  256  is 
reserved  for  a  special  "clear  code",  and  entry  #257  is  reserved  for 
a  special  "End  of  Information"  code,  therefore  the  first 
multi-octet  entry  to  the  table  is  made  at  position  258. 

Since  codes  are  written  using  as  few  bits  as  possible,  WriteCode!) 
starts  out  with  9  bit  codes  since  the  new  entries  are  greater  than 
255  but  less  than  512.  When  table  entry  512  is  added,  WriteCode 
switches  to  10  bit  codes.  Likewise,  it  switches  to  11  bit  codes  at 
1024  and  to  12  bit  codes  at  2048.  The  table  is  limited  to  12  bit 
codes,  so  when  entry  4094  is  reached,  a  ClearCode  is  written  and 
the  compresor  re-initilaizes  the  table  and  starts  writing  out  9  bit 
codes  again.  Each  encoded  pel  array  begins  with  a  Clear  code  and 
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ends  with  an  End  of  Infonnatjon  code. 

LZW  Decoding 

The  procedure  for  decompression  is  described  by  the  following 
pseudocode : 

while  < (CodeNextCode 0 !-End  of  Information  code) { 
if  ( (Code  —  Clear  code) { 

InitializeTable  0 ; 

Code  ■■  GetNextCode  ( )  ; 
if  (Code  End  of  Information  code  ) 
break; 

WriteCode (StringFromCode (Code) ) ; 

OldCode  —  Code; 

}  */end  of  Clear  code  case*/ 

else{ 

if  (IsInTable (Code) ) { 

WriteString (StringFromCode (Code) ) ; 

AddStringToTable (StringFromCode (OldCode) +FirstChar 
(StringFromCode (Code) ) ) ; 

WriteString (OutString) ; 

AddStringToTable (OutString) ; 

OldCode  -  Code; 

)else{ 

OutString-StringFromCode (OldCode ) 

+  FirstChar (StringFromCode (Code) ) ; 

AddStringToTable (OutString) ; 

OldCode  •  Code; 

WriteString (OutString) ; 

) 

}/*end  of  not -Clear  code  case*/ 

)/*end  of  while  loop*/ 

The  function  GetNextCode  ( )  retrieves  the  next  code  from  the 
LZW-coded  data.  It  must  keep  track  of  bit  boundaries.  It  knows  that 
the  first  code  that  it  gets  will  be  9-bit  code.  We  add  a  table 
entry  each  time  we  get  a  code,  so  GetNextCode ( )  must  switch  over  to 
10-bit  as  soon  as  string  #511  is  stored  into  the  table. 

The  function  StringFromCode ( )  gets  the  string  associated  with  a 
particular  code  from  the  string  t^Uble. 

The  function  AddStringToTable ( )  adds  a  string  to  the  string  table. 
The  "+”  sign  joining  the  two  parts  of  the  argument  to 
AddStringToTable  indicate  the  string  concatenation. 

StringFromCode ()  looks  up  the  string  associated  with  a  given  code. 

WriteString ( )  adds  a  string  to  the  output  stream. 
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The  'local  colour  precision*  parameter  declares  the  precision  of 
'cell  colour  specifiers'.  It  applies  only  to  computer  graphics 
standards  that  support  the  both  direct  amd  indexed  specification  of 
colour.  If  indexed  colour  selection  is  used,  then  this  parameter 
specifies  the  colour  index  precision.  If  direct  colour  selection  is 
used,  then  then  this  parameter  specifies  the  colour  precision. 
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Relationwhlp  to  raairtieular _ atandarda; 

1)  C6M  Functional  SpaciFication  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

The  LCP  (local  color  precision)  pareuneter  declares  the  precision  of 
the  cell  colour  specifiers.  The  precision  is  for  either  indexed  or 
direct  colour,  according  to  the  COLOUR  SELECTION  MODE  of  the 
picture .  The  form  of  the  parameter  is  encoding  dependent .  If  the 
picture  uses  indexed  colour  selection,  then  the  form  of  the 
parameter  is  the  same  as  that  of  COLOUR  INDEX  PRECISION.  If  the 
picture  uses  direct  colour  selection,  then  the  form  of  the 
parameter  is  the  same  as  that  of  COLOUR  PRECISION.  Since  the  array 
may  be  compressed,  its  length  may  not  be  able  to  be  calculated 
directly  from  the  number  of  pel  array  colour  specifier  values . 
Consequently,  the  pel  array  is  treated  as  an  array  of  16  bit 
integer  words  and  its  length  is  specified  by  the  pel  array  length 
parameter . 

A  functional  description  of  the  Pel  Array  generalized  drawing 
primitive  parameters  is : 

Parameters ; 

function  identifier  (I)  as  assigned  by  the  Registration 
Authority 

point  list(nP}  contains  the  three  points  P,  Q,  and  R 

data  record (D) 


Items  for  Data  Record: 

nx 

ny 

encoding 

LCP 

pel  array  length 

start  of  pel  array  colour  specifiers 


Data  Record  Description: 

The  data  record  contains  the  dimensions  of  the  pel  array,  its 
encoding  type,  its  local  colour  precision,  and  the  pel  array 
itself . 
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2)  CQl  Encodings  (reference  ISO  8632  CGM;  Parts  2.3^4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  • i  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integer;  . 
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3)  6KS  Functional  Specification  {reference  ISO  7942  GKS 
Functional  Description) 

This  GDP  is  applicable  at  level  Oa  and  above.  The  corner  points  are 
transformed  to  NDC  and  the  pel  array  through  those  points  is  then 
drawn.  The  pel  array  colour  specifiers  may  be  either  index  or 
direct  colour  values,  as  determined  by  the  value  of  the  colour 
specification  type  parameter.  If  the  pel  array  uses  indexed  colour 
selection,  then  the  local  colour  precision  specifies  the  length  of 
the  index  values,  in  bits .  If  the  pel  array  uses  direct  colour 
selection,  then  the  local  colour  precision  specifies  the  length  of 
the  direct  RGB  colour  values  in  bits.  Since  the  array  may  be 
compressed,  its  length  may  not  be  able  to  be  calculated  directly 
from  the  number  of  pel  array  colour  specifier  values .  Consequently, 
the  pel  array  is  treated  as  an  array  of  16  bit  integer  words  and 
its  length  is  specified  by  the  pel  array  length  parameter . 

A  functional  description  of  all  input  parameters  is: 


Name  Coordinate  System  Values  Data  Type 

number  of  points  (3)  I 

corner  points  (P,Q,  and  R)  WC  3xP 


GDP  identifier  as  assigned  N 

GDP  data  record: 
nx,ny  (21) 

encoding  (packed,  run-length,  T.4,  T.6,  LZW)  E 

colour  specification  type  (indexed,  direct)  E 

local  colour  precision  I 

pel  array  length  I 

pel  array  colour  specifiers  (nx*ny*local  colour  precision)  I*pel 

array 

length 


Errors : 

5  GKS  not  in  proper  state;  GKS  shall  be  in  the  state  MSAC  or 
In  the  state  SGOP 
100  Humber  of  points  is  invalid 
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4)  GKS  FORTRAM  language  binding  (reference  ISO/IEC  8651-1,  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GDpqrs"  form 
(as  defined  in  subclause  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  GDP  (pqrs  is  to  be  assigned  by  the  Registration  Authority  to 
correspond  to  the  assigned  Register  Identifier) : 


SUBROUTINE  GDpqrs (  N,  PXA,  PYA,  NX,  NY,  lENCODE,  ICSPEC,  LCP, 
+IPAL,  IP ACS)  , 


Input  Parameters : 
INTEGER  N 

REAL  PXA(3),  PYA(3) 
INTEGER  NX,  NY 

INTEGER  lENCODE 

INTEGER  ICSPEC 

INTEGER  LCP 
INTEGER  IPEL 
INTEGER  IPACS(IPEL) 


number  of  points  (3) 

P,Q,  and  R  corner  points 

number  of  pels  per  line;  number  of 

lines 

encoding  (packed,  run-length,  T.4,  T.6, 
LZW) 

colour  specification  type ( indexed, 
direct ) 

local  colour  precision 
pel  array  length 

pel  array  colour  specifiers 
(number  of  values  is  nx*ny*local  colour 
precision) 


b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  GDP  through  the  GGDP  function  of  subclause  9.3  of  the  GKS 
FORTRAN  language  binding  standfird: 

Parameters  used  by  the  Pack  Data  Record  function  for  the  Input  Data 
Record: 


Integer 

IL 

5  +  pel  array  length  (which  depends  the 

relationship  of  LCP  to  integer  precision 
integer  precision  and  encoding) 

Integer 

IA(1) 

nx 

Integer 

IA(2) 

ny 

Integer 

IA(3) 

encoding 

Integer 

IA(4) 

LCP 

Integer 

IA(5) 

pel  array  length 

Integer 

IA(6) 

start  of  pel  array  colour  specifiers 

Integer 

RL 

0 

Integer 

SL 

0 

The  Unpack  Data  Record  function  is  not  required  by  this  escape. 
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5)  Pascal  languaga  binding  (reference:  ISO/IEC  8651-2,  GKS 

Language  Bindings;  Part  2:  Pascal) 


The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GEscape"  as  defined  in  subclause  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 

NumPoints  -  3; 

Points  :  GAPointArray; 

GEGDPCurveProperty6  -  (paclced,  run-length,  T.4,  T.6,  LZW)  ; 
GEGDPCurveProperty7  «  (indexed,  direct) ; 


GRGDPData  -  RECORD 

CASE  GDPId  :  GTGDPDataTag  OF 
1:  ( 

00001  PelsPerLine 

OOOOl  LinesPerArray 

00001  EncodingType 

00001  ColourSpecificationType 

00001  LocalColourPrecision 

00001  PelArrayLength 

OOOOl  PelArrayColourSpecifiers 


END; 


:  INTEGER; 

:  INTEGER; 

:  GEGDPCurveProperty6; 

:  GEGDPCurveProperty?; 

:  INTEGER; 

:  INTEGER; 

:  array 

[1. .PelArrayLength] 
of  INTEGER)  ; 
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6)  6KS  Ada  languaga  binding  (reference  ISO/IEC  8651-3,  GKS 
Language  Bindings;  Part  3:  Ada) 

Registered  GDP’s  are  in  a  library  package  named  GKS_GDP .  GKS  Ada 
provides  a  data  type  package,  GKS__TYPES  which  provides  types 
declarations . 

The  binding  for  the  "procedure  PEL__ARRAY"  form  (as  defined  in 
subclause  4.1  of  the  GKS  Ada  language  binding)  of  the  GDP  is: 


— GDP  function  for  a  Pel  Array. 

— Data  type  GDP_DATA_RECORD  is  defined  in  package  GKS_GDP . 

— GDP_ID  and  other  data  types  are  defined  in  package  GKS_TYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package  GKS_GDP  is 

type  CORNER_POINTS  is  new  WC . P01NT_ARRAY  (1..3); 
type  ENCODING_TYPE  is  (PACKED,  RUN_LENGTH,  T.4,  T.6,  LZW) ; 
type  COLOaR_SPECiriCATION_TYPE  is  (indexed,  direct); 
type  PEL  ARRAY_COLOUR  SPECIFIERS  is  array  (NATURAL  rangeo)  of 
ESCAPE* INTEGER) ;  “ 

type  PEL3RRA^_DATA_REC0RD  is 
record”  ” 

PELS^PER  LINE 
LINES  PER  ARRAY 
ENCODING  “ 

colodr_spec ificat ion 

LOCAL_COLOUR_PREC IS ION 
PEL_ARRAY  LENGTH 

pel_array“ 

end;  ” 

procedure  PEL_ARRAY 
(  CORNER_POINTS 
PEL_ARRAY_REC0RD 

)  ; 


ESCAPE_INTEGER; 

ESCAPE  INTEGER; 

ENCODING  TYPE; 

COLOUR_SPECir ICATION_TYPE ; 
ESCAPE_  INTEGER; 

ESCAPE_  INTEGER; 

PEL  ARRAY  COLOUR  SPECIFIERS; 


:in  BE2IER_POINTS; 

:in  PEL  ARRAY  DATA  RECORD; 


— more  GDP  procedures  can  be  inserted  here 
end  GKS  GDP; 
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Sponsortnq  Authorlt 


Class  of  Qraphlcal  Item:  I  ESCAPE 


Specific  Escape  I  Function  Identifier:  |  Set  Indexed  Colour  Resoonse 


Description 


This  escape  (unction  sets  a  value  for  the  indexed  coiour  response  curve.  This  curve  is  used  to  provide  exact 
photometric  information  in  terms  of  density  for  indexed  colour  specifications  contained  in  pel  array  primitivas. 
See  attached  sheets  for  additional  details. 


Additional  Comments 


This  escape  is  intended  for  use  in  conjunction  with  the  pel  array  generalized  drawing  primitive,  although  it  could 
be  used  for  rendering  other  primitives  as  well. 


Justification  for  Inclusion 


Photometric  information  in  terms  of  density  for  indexed  colour  specifications  contained  in  pel  array  primitives  is 
needed  if  output  devices  are  to  reproduce  input  pel  arrays  precisely.  Many  proprietary  systems  for 
defining/storing/transferring  raster  image  data  provide  this  capability.  This  is  one  in  a  set  of  escapes  that 
provide  extended  raster/image  data  capabilities  enabeling  the  family  of  computer  graphics  standards  to  meet  the 
requirements  of  office  document  generation/exchange  and  technical  publications. 


_  Relationship  to  Standards 


1)  ISO  7942  (GKS)  •  Specifies  a  registered  escape  as  defined  in  5.2. 

2)  ISO  8632  (CGM)  •  Specifies  a  registered  escape  as  defined  in  5.8.1. 


3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  escape. 
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Peacriptioai. 

The  purpose  of  the  Set  Indexed  Colour  Response  escape  function  is 
to  define  a  "curve"  providing  exact  photometric  interpretation 
information  in  terms  of  optical  density  for  indexed  colour  image 
data  contained  in  pel  array  primitives.  In  particularr  if  the 
index  values  represent  ranges  of  a  monochrome  value  such  as  gray, 
this  escape  can  be  used  to  provide  more  exact  photometric 
interpretation  information  for  gray  scale  image  data.  The  default 
curve  is  linear  in  intensity/ ref lectMce. 

Since  optical  density  is  specified  in  terms  of  fractional  numbers, 
Real  numbers  are  used  for  these  values.  Optical  densitometers 
typically  measure  densities  within  the  rainge  of  0.0  to  2.0.  If  the 
indexed  colour  response  curve  is  known  for  the  data  in  a  pel 
array,  and  if  the  indexed  colour  response  of  the  output  device  is 
known,  then  an  intelligent  conversion  can  be  made  between  the 
input  data  and  the  output  device.  For  example,  the  output  can  be 
made  to  look  just  like  the  input.  In  addition,  if  the  input  image 
lacks  contrast  (as  can  be  seen  from  the  response  curve) ,  then 
appropriate  contrast  enhancements  cam  be  made. 

The  purpose  of  the  indexed  colour  response  curve  is  to  act  as  a 
"lookup"  table  mapping  values  from  0  to  2*" (local  colour 
precision)-!  into  specific  density  values.  The  0th  element  of  the 
indexed  colour  response  curve  array  is  used  to  define  the  colour 
response  value  for  all  pels  having  an  index  value  of  0,  the  1st 
element  of  the  indexed  colour  response  curve  array  is  used  to 
define  the  colour  response  value  for  all  pels  having  a  value  of  1, 
and  so  on,  up  to  2** (local  colour  precision)-!.  It  is  permissible 
to  have  a  indexed  colour  response  curve  even  for  bilevel  (1-bit) 
pel  arrays .  The  indexed  colour  response  curve  will  have  2  values . 

Implementers  may  wish  to  purphase  a  Kodak  Reflection  Dens  ity 
Guide,  catalog  number  146,5947,  available  for  $10  or  so  at 
prepress  supply  houses,  and  use  it  to  determine  reasonable  density 
values  for  their  scanner  or  frame  grabber.  If  this  is  not 
practical  the  default  curve  that  is  linear  in 
intensity/ reflectance  can  be  used. 
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Raiationahip  to  Particular  ataadarda ; 

1)  C6M  runctionml  Specification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

The  local  colour  precision  value  in  this  escape  should  match  that 
used  in  subsequent  Pel  Array  GDPs  when  index  colour  is  used.  A 
functional  description  of  the  Set  Indexed  Colour  Response  escape 
parameters  is: 

Pareuneters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 

LCP  (local  colour  precision)  (I) 
colour  response  curve  (  (2**LCP)  *  R) 

Items  for  Data  Record: 

LCP  (local  colour  precision) 
colour  response  curve  (0) 
colour  response  curve  (1) 

•  •  • 

colour  response  curve  ((2**LCP)-1  ) 

Data  Record  Description: 

The  parameters  define  the  local  colour  precision  and  indexed' 
colour  response  curve  for  pel  array  data. 


2)  CQl  Sncodiags  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string’s  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  62CS  Functional  SpaciFication  (reference  ISO  7942  GKS 
Functional  Description) 

The  set  dash  escape  is  applicable  at  GKS  level  Oa.  A  functional 
description  of  its  parameters  is  given  below: 


Name  Values  Data  Type 

escape  function  identifier  as  assigned  N 

input  data  record: 

LCP  (local  colour  precision) 
colour  response  curve 

output  data  record: 
none 

Errors : 

8  GKS  not  In  proper  state:  GKS  shall  he  In  one  of  the  states 
GKOPfWSOP,  WSAC,  or  SGOP 

4)  GKS  FORTBAK  language  binding  (reference  ISO/IEC  8651-1, 

GKS  Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs”  form 
(as  defined  in  sxibclause  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrsdCP,  CRC) 

Input  Parameters: 

INTEGER  LCP  local  colour  precision 

REAL  CRC(2**LCP)  colour  response  curve 

Output  Parzuneters: 

NONE 

b)  The  following  parauneters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  subclause  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 


I 

(2**LCP) *R 


Parameters  used  by  the  Pack  Data  Record  function  for  the  Input  Data 
Record: 


Integer  IL 
Integer  IA(1) 
Integer  RL 
Real  RA(1) 
Real  RA(2) 


1 

LCP  (local  colour  precision) 
2**LCP 

colour  response  curve  (0) 
colour  response  curve  (1) 


Real  RA(2**LCP)  colour  response  curve  ({2**LCP)-1  ) 

Integer  SL  0 
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The  Unpack  Data  Record  function  is  not  required  by  this  escape. 


S)  Pascal  langnaga  binding  (reference:  ISO/IEC  8651-2  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GEscape"  as  defined  in  subclause  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


GREscapeOataIn  »  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 
1:  ( 

UOOOl  LocalColourPrecision:  INTEGER; 

UOOOl  ColourResponseCurve  : 

array  [1. . (2**LocalColourPrecision) ] 
of  REAL) ; 

END; 

GREscapeDataOut  -  RECORD 

CASE  EscapelD  :  GTEscapeDataTag  of 
1:  ()  ;  (*Null  Record*) 

END; 
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6)  6KS  Ada  language  binding  (reference  ISO/IEC  8651-3 r  (aKS 
Language  Bindings;  Part  3:  Ada) 

Registered  ESCAPE'S  are  in  a  library  package  named  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  package,  GKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  -procedure  SET_INDEXED_COLOOR_RESPONSE"  form 
(as  defined  in  subclause  4.1  of  the  GKS  Ada  language  binding)  of 
the  ESCAPE  is: 


— Escape  function  to  set  the  indexed  colour  response  curve  for  a 
— pel  array. 

— Data  types  ESCAPE_ID  and  ESCAPE_FLOAT  are  defined  in  package 
— GKS_ESCAPE . 

— Other  data  types  are  defined  in  package  GKS_TYPES. 

with  GKS__TYPES; 
use  GKS_TYPES; 
package  GRS_ESCAPE  is 

type  COLOUR  RESPONSE_CURVE  is  array 

(SMALL^NATURAL  range  <>)of  ESCAPE^FLOAT : 
type  INDEXEDjCOLOUR_RESPONSEJElECORD  is” 
record  ” 

LOCAL_COLOUR  PRECISION  :in  INTEGER; 

COLOUR  RESPONSE  :in  COLOUR__RESPONSE  CURVE 

“  (0 . . (2**LOCAL_COLOUR_PRECISION-l ) ) ; 

end  record; 

procedure  SET_INDEXED_COLOUR_RESPONSE 

(COLOUR_RESPONSE  :in  INDEXED j:OLOUR_RESPONSE_RECORD  ) ; 

— more  ESCAPE  procedures  can  be  inserted  here 

end  GKS  ESCAPE; 
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Clasa  of  Graphical  Itam:  I  ESCAPE 


Specific  Escape  I  Function  Identifier:  |  Set  Direct  Colour  Response  


Description 


This  escape  function  sets  a  value  for  the  direct  coiour  response  cunre.  This  curve  is  used  to  provide  exact 
photometric  information  in  terms  of  intensity  for  direct  colour  specifications  contained  in  pel  array  primitives. 
See  attached  sheets  for  additional  details. 


_  Additional  Comments 


This  escape  is  intended  for  use  in  conjunction  with  the  pel  array  generalized  drawing  primitive,  although  it  could 
be  used  for  rendering  other  primitives  as  wall. 


_ Justification  for  inclusion 


Photometric  information  in  terms  of  intensity  for  directly  specified  coiour  contained  in  pel  array  primitives  Is 
needed  if  output  devices  are  to  reproduce  input  pel  arrays  precisely.  Many  proprietary  systems  for 
defining/storing/transfarring/viewing  raster  image  data  provide  this  capability.  This  is  one  in  a  set  of  escapes 
that  provide  extended  rastar/image  data  capabilities  enabeling  the  family  of  computer  graphics  standards  to 
meet  the  requirements  of  office  document  ganaration/exchange  and  technical  publications. 


_ _ Relationship  to  Standards 


1 )  ISO  7942  (GKS)  •  Specifies  a  registered  escape  as  defined  in  5.2. 


2)  ISO  8632  (CGM)  -  Specifies  a  registered  escape  as  defined  in  5.8.1. 

3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  escape. 
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The  purpose  of  the  Set  Direct  Colour  Response  escape  function  is 
to  define  a  "curve"  providing  exact  photometric  interpretation 
information  in  terms  of  intensity  for  direct  colour  image  data 
contained  in  pel  array  primitives.  Three  colour  response  curves, 
one  each  for  Red,  Green  and  Blue  color  information  are  defined. 
The  Red  entries  come  first,  followed  by  the  Green  entries, 
followed  by  the  Blue  entries.  The  default  curves  are  linear  in 
intensity/ ref lectance .  The  length  of  each  subcurve  is  2**  (local 
colour  precision) ,  using  the  same  local  colour  precision  value  as 
subsequent  pel  array  generalized  drawing  primitives .  Each  entry  is 
a  16  integer  value.  0  represents  the  minimxun  intensity,  and  65535 
represents  the  maximum  intensity.  Black  is  represented  by  (0,0,0), 
and  white  by  (65535,  65535,  65535) .  Therefore,  a  color  response 
curve  entry  for  direct  (RGB)  colour  data  with  a  local  colour 
precision  of  8  bits  would  have  3  *  256  entries,  each  consisting  of 
a  16  bit  integer. 
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Ralatlonahip  to  particular  standards: 

1)  C6M  Functional  Spacificatlon  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

The  local  colour  precision  value  in  this  escape  should  match  that 
used  in  subsequent  Pel  Array  GDPs  when  index  colour  is  used.  A 
functional  description  of  the  Set  Indexed  Colour  Response  escape 
parameters  is : 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 

LCF  (local  colour  precision)  (I) 
red  response  curve  (  (2**LCP)  *  I) 
green  response  curve  (  (2**LCP)  *  I) 
blue  response  curve  (  (2**LCP)  *  I) 

Items  for  Data  Record: 

LCP  (local  colour  precision) 
red  response  curve  (0) 
red  response  curve  (1) 

•  •  • 

red  response  curve  ((2**LCP)-1  ) 
green  response  curve  (0) 
green  response  curve  (1) 

•  •  • 

green  response  curve  ((2**LCP)-1  ) 
blue  response  curve  (0) 
blue  response  curve  (1) 

•  •  • 

blue  response  curve  ((2**LCP)-1  ) 

Data  Record  Description: 

The  parameters  define  the  local  colour  precision  and  indexed 
colour  response  curve  for  pel  array  data. 


2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4 .  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  GKS  Functional  Specification  (reference  ISO  7942  GKS 
Functional  Description) 

The  set  dash  escape  is  applicable  at  GKS  level  Oa  and  above .  A 
functional  description  of  its  parameters  is  given  below: 


Name  Values  Data  Type 

escape  function  identifier  as  assigned  N 

input  data  record: 

LCP  (local  colour  precision) 
red  response  curve 
green  response  curve 
blue  response  curve 

output  data  record: 
none 

Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  in  one  of  the 
states  GKOP,mOP,  WSAC,  or  SGOP 

4)  GKS  FORTRAN  language  binding  (reference  ISO/IEC  8651-1, 

GKS  Language  Bin»fings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  siibclause  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqr3(LCP,  RCRC,  GCRC,  BCRC) 

Input  Parameters: 

INTEGER  LCP  local  colour  precision 

INTEGER  RCRC(2**LCP)  red  response  curve 
INTEGER  GCRC(2**LCP)  green  response  curve 
INTEGER  BCRC(2**LCP)  blue  response  curve 

Output  Pareuneters: 

NONE 


I 

(2**LCP) *I 
(2**LCP) *I 
(2**LCP) *I 
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b)  The  followl'tg  parameters  are  proposed  for  use  when  acce  ‘^sing 
this  escape  through  the  GESC  function  of  subclause  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Parameters  used  by  the  Pack  Data  Record  function  for  the  Input  Data 
Record: 


Integer  IL 
Integer  IA(1) 

Integer  IA(2) 

Integer  IA(3) 

•  •  • 

Integer  IA(2**LCP+1) 
Integer  lA(2**LCP+2) 
Integer  IA(2**LCP+3) 

Integer  IA(2*2**LCP+1) 
Integer  IA(2*2**LCP+2) 
Integer  IA(2*2**LCP+3) 

Integer  IA(3*2**LCP+1) 
Integer  RL 
Integer  SL 

The  Unpack  Data  Record  function 


1  +  3*(2**LCP) 

LCP  {local  colour  precision) 
red  response  curve  (0) 
red  response  curve  (1) 

red  response  curve  ((2**LCP)-1  ) 
green  response  curve  (0) 

green  response  curve  (1) 

green  response  curve  ((2**LCP)-1  ) 

blue  response  curve  (0) 
blue  response  curve  (1) 

blue  response  curve  ({2**LCP)-1  ) 

0 

0 

Is  not  required  by  this  escape. 


5)  Pascal  language  binding  (reference:  ISO/IEC  8651-2,  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  Is  proposed  for  the  procedure 
"GEscape"  as  defined  In  s\ibclause  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  Identifier  at  reglstratxon) : 


GREscapeOataIn  *  RECORD 

CASE  Escape Id  :  GTEscapeDataTag  of 
1:  ( 

UOOOl  LocalColourPreclslon  :  INTEGER; 

UOOOl  RedResponseCurve 

:  array  (1 . . (2**LocalColourPreclslon) ]  of  INTEGER) 
UOOOl  GreenResponseCurve 

:  array  [1 . . (2**LocalColourPreclslon) J  of  INTEGER) 
UOOOl  BlueResponseCurve 

:  array  [1 . . (2**LocalColourPreclslon) ]  of  INTEGER) 

END; 

GREscapeOataOut  -  RECORD 

CASE  EscapelD  :  GTEscapeDataTag  of 
1:  0  ; 

(♦Null  Record*) 

END; 
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6)  GICS  Ada  language  binding  (reference  ISO/IEC  8651-3,  GKS 
Language  Bindings;  Part  3:  Ada) 

Registered  ESCAPE'S  are  in  a  library  package  named  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  package,  GKSJTYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SET_DIRECT_COLODR_RESPONSE"  form  (as 
defined  in  subclause  4.1  of  the  GKS  Ada  language  binding)  of  the 
ESCAPE  is : 


“Escape  function  to  set  the  indexed  colour  response  curve  for  a 
— pel  array. 

— Data  types  ESCAPE_ID  and  ESCAPE  FLOAT  are  defined  in  package 
“GKS_ESCAPE . 

— Other  data  types  are  defined  in  package  GKS_TYPES. 

with  GKSJTYPES; 
use  GKS_TYPES; 
package  GKS__ESCAPE  is 

type  DIRECT__COLOUR_RESPONSE__CURVE  is  array 
( SMALL  JtATURAL  range  <>)of  INTEGER; 
type  DIRECT_COLOaR_RESPONSE__RECORD  is 
record  —  —  — 

LOCAL__COLOUR__PRECISION  ;in  INTEGER; 

COLOUR_RESPONSE  ;  in  DIRECT_COLOUR__RESPONSE_CURVE 

(0. . (2"*L0CAL  COLOUR  PRECISION-1)); 

end  record; 

procedure  SET_D IRECT_COLOaR_;_RESPONSE 

(COLOUR_RESPONSE  :in  DIRECT_COLOUR_RESPONSE_RECORD  ); 

— more  ESCAPE  procedures  can  be  inserted  here 

end  GKS  ESCAPE; 
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Proposal  Number: 


Data  of  Presentation:  I  6  October  1989 


Authorit 


Class  at  Graphical  Item:  I  ESCAPE 


Specific  Escape  I  Function  Identifier:  I  Seqment  List 


Description 


This  escape  function  defines  an  association  between  the  name  of  a  global  segment  (in  a  CGM)  and  an  identifier. 
This  identifier  is  used  by  the  receiving  system  to  locate  the  segment  Its  purpose  is  to  allow  such  segments  to  be 
externally  defined  aruf  included  in  a  CGM  file  by  reference.  This  escape  applies  only  to  the  CGM  standard. 


Additional  Comments 


_ _  _  Justification  for  Inclusion 


In  many  ‘closed*  interchange  environments  it  is  useful  to  build  libraries  of  standard  graphical  objects  that  can  be 
incorporated  into  pictures  by  reference.  This  leads  to  more  compact  picture  descriptions  and  to  mors  uniform 
appearance. 


Relationship  to  Standards 


1 )  ISO  7942  (GKS)  -  Does  not  apply. 


2)  ISO  6632  (CGM)  •  Specifies  a  registered  escape  as  defined  in  5.8.1. 


3)  ISO  8651  (GKS  Language  Bindings)  -  Does  not  apply. 
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Paaeription: 

Sagnant  List  permits  global  segments  to  externally  defined.  This 
escape  is  only  applicable  to  the  CGM  standard.  Each  segment  name  in 
the  segment  name  list  is  associated  with  the  corresponding 
identifier  in  the  external  identifier  list.  The  total  number  of 
elements  in  both  lists  must  be  Identical  and  is  given  by  the  number 
of  correspondences.  The  effect  is  as  if  each  segment  definition 
that  is  externally  referenced  were  included  within  the  metafile 
descriptor  as  a  global  segment  definition. 

The  content  and  structure  of  the  identifiers  in  the  external 
identifier  list  are  not  standardized  by  this  escape  element,  and 
are  expected  to  be  defined  by  application  profiles .  However,  the 
following  scheme  is  suggested  for  general  use  in  CGMs  that  do  not 
conform  to  a  specific  application  profile: 

1)  each  identifier  is  a  string  consisting  of  three  portions; 

2)  the  portions  are  separated  from  each  other  by  the  solidus 
character  (/) ; 

3)  the  first  portion  is  the  local  file  name  of  a  CGM  file  where  the 
segment  may  be  found; 

4)  the  second  portion  gives  the  picture  number  within  the  file 
designated  in  the  first  portion;  a  value  of  zero  (0)  designates  a 
global  segment  within  that  file; 

5)  the  third  portion  gives  either  the  local  segment  name  within  the 
picture  designated  by  the  second  portion  or  the  global  segment  name 
in  case  the  second  portion  designates  a  global  segment. 

For  example,  "My  Symbol  File/0/1"  designates  global  segment  "1"  in 
file  "My  Symbol  File".  (Note  that  global  segment  naunes  are  realized 
as  integers  in  the  CGM,  so  character  codes  in  identifiers  are 
translated  into  equivalent  integer  values  as  necessary  to  determine 
their  meanings . ) 

If  any  segment  name  or  identifier  is  invalid,  then  that  element  of 
both  lists  shall  not  be  processed  and  no  association  shall  be 
established.  If  the  number  of  correspondences  is  invalid,  the 
escape  shall  be  ignored.  If  the  number  of  correspondences  and  the 
contents  of  the  two  lists  are  not  consistent,  then  the  escape  shall 
be  ignored.  If  any  identifier  cannot  be  translated  into  a  valid 
external  reference,  then  that  element  of  both  lists  shall  be 
ignored. 


I 


I 
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Relationahip  to  particular _ atandagda; 


1)  CGM  Functional  Specification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

A  functional  description  of  the  Select  General  Fill  escape 
parameters  is : 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 
Authority 

data  record  (D) : 

number  of  correspondences  (the  number  of  elements  in  both 
the  segment  name  list  and  the  external  identifier  list) 
segment  name  list  (a  list  of  segment  names) 
external  identifier  list  (a  list  of  external  identifiers) 


Items  for  Data  Record: 

number  of  correspondences  (I) 
segment  name  list  (nSN) 
external  identifier  list  (nS) 


Data  Record  Description: 

The  parameters  designate  a  correspondence  between  a  set  of 
segment  names  and  a  set  of  external  identifiers. 

2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items), 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 

3)  GKS  Functional  Specification  (reference  ISO  7492,  GKS 
Functional  Specification) 

The  proposer  only  wishes  to  use  this  escape  with  the  CGM  standard. 

4)  GKS  FORTRAN  language  binding  (reference  ISO/IEC  8651-1,  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

The  proposer  only  wishes  to  use  this  escape  with  the  CGM  standard. 
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5)  GKS  Pascal  language  binding  (reference:  ISO/IEC  8651-2, 

GKS  Language  Bindings;  Part  2:  Pascal) 

The  proposer  only  wishes  to  use  this  escape  with  the  CGM  standard. 

6)  GKS  Ada  language  binding  (reference  ISO/ ICC  8651-3,  GKS 
Language  Bindings;  Part  3: Ada) 

The  proposer  only  wishes  to  use  this  escape  with  the  CGM  standard. 


I  Dat>  of  Presentation;  |  6  October  1989  _ 

I  Sponsoring  Authority;  I  ANSI 
I  Class  of  Graphical  Hfftn;  I  ESCAPE 

I  Specific  Escap*  I  Function  Identifier;  I  Glyph  Association  I 


_ Daacriptlon _ _ _ _ 

This  escape  function  defines  an  association  between  a  glyph  collection  and  a  set  of  codes.  Such  an  association  is 
commonly  called  a  ‘character  set*  This  escape  is  applicable  only  to  the  CGM  standard.  The  designated  tail 
sepuencs  is  used  to  invoke  defined  ‘character  set*  within  a  CGML  The  glyph  collection  can  be  either  a  registered 
glyph  collection.  Glyph  identifiers  may  be  registered  identifiers  or  may  have  only  private  meaning. 


Additlonat  Comments 

None. 


Justification  for  inclusion 

Presently,  the  CGM  standard  allows  only  coded  character  sets  defined  or  registered  according  to  the  procedures 
of  ISO  646,  ISO  2022.  or  ISO  2375  to  be  used  in  text  strings.  In  office  systems  standards  the  used  of  such 
coded  character  sets  is  being  replaced  by  a  new  set  of  glyph  identifier  and  glyph  collection  identifier  registration 
procedures  that  de-couple  the  notion  of  glyph  (or  ‘character*)  from  the  code  used  to  represent  that  glyph  in 
interchange.. Without  this  extension,  these  glyphs  and  glyph  collections  cannot  be  used  within  a  CGM,  since  the 
associated  registers  do  not  record  any  association  of  gl^hs  to  codes.  Further,  there  are  additional  requirements 
for  user  defined  fonts  and  user  defined  character  sets  that  can  conveniently  utilize  an  escape  that  allows  an 
association  between  codes  and  glyphs  to  be  defined  within  a  CGM.  This  escape  is  designed  to  meet  both  these 
needs. 


_ Relationship  to  Standards _ 

1 )  ISO  7942  (GKS)  •  Does  not  apply. 

2)  ISO  8632  (CGM)  -  Specifies  a  registered  escape  as  defined  in  5.8.1. 

3)  ISO  8651  (GKS  Language  Bindings)  •  Doss  not  apply. 

4)  ISO  10036  (Procedure  for  registration  of  glyph  and  glyph  collection  identifiers)  -  Identifiers  registered 
according  to  these  procedures  can  be  used  in  this  Escape  function. 
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Paacription: 

Glyph  Association  permits  the  definition  of  "character  sets" 
constructed  by  associating  glyph  Identifiers  with  points  in  a  code 
tcUsle  (in  the  sense  of  ISO  2022) .  This  escape  is  only  applicable  to 
the  CGM  standard.  The  number  of  bytes  in  each  code  word  is  defined 
by  code  bytes.  Each  code  in  the  code  list  is  associated  with  the 
corresponding  glyph  identifier  in  the  glyph  identifier  list.  The 
total  number  of  elements  in  both  lists  must  be  identical  and  is 
given  by  the  number  of  glyphs.  The  designation  tail  sequence  must 
correspond  to  one  of  the  character  sets  listed  in  the  CHARACTER  SET 
LIST  element r  and  establishes  the  relationship  between  the 
character  set  type  in  that  element  and  the  codes  in  this  escape 
function.  The  glyph  collection  identifier  may  be  used  to  associate 
the  glyph  collection  with  its  registered  identifier  for  information 
purposes  only.  The  default  glyph  identifier  designates  the  glyph 
that  is  used  for  all  unspecified  bit  combinations  (codes) . 

The  content  and  structure  of  the  identifiers  in  the  glyph 
identifier  list  are  not  standardized  by  this  escape  element,  and 
may  be  defined  by  application  profiles  or  taken  from  those  in  the 
International  Register  of  Glyph  Identifiers  established  by  ISO 
10036.  The  glyph  collection  identifier  is  either  a  registered  glyph 
collection  name  or  is  a  null  string. 

The  number  of  bytes  in  a  code  point  in  both  this  element  and  in  the 
CHARACTER  SET  LIST  must  be  consistent.  If  they  are  not,  this 
element  shall  be  ignored.  If  the  number  of  correspondences  and  the 
contents  of  the  two  lists  are  not  consistent,  then  this  escape 
shall  be  ignored.  If  any  glyph  identifier  is  not  recognized,  then 
the  corresponding  code  shall  be  set  the  default  glyph  identified  by 
the  default  glyph  identifier.  The  code  list  need  not  contain  a  code 
point  for  each  possible  bit  combination.  Those  code  points  that  are 
omitted  shall  use  the  default  glyph  identified  by  the  default  glyph 
identifier .  If  the  default  glyph  identifier  is  not  recognizable, 
the  asterisk  glyph  (*)  shall  be  used. 
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Rr  \ationahip  to _ partl^e-alar  atandagda; 


1)  C6M  runctional  Spaclflcatlon  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

A  functional  description  of  the  Select  General  Fill  escape 

parameters  is : 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 
Authority 

data  record  (D) : 

number  of  glyphs  (the  number  of  elements  in  both  code  list 
and  glyph  identifier  list) 

code  bytes  (the  number  of  bytes  in  each  element  of  code 
list) 

code  list  (a  list  of  codes) 

glyph  identifier  list  (a  list  of  glyph  identifiers) 

designation  tail  sequence  (the  tail  sequence  used  to 
designate  this  chaarcter  set  in  the  CGM) 

glyph  collection  identifier  (the  registered  identifier  -  if 
any  -  of  the  collection  of  glyphs  in  the  glyph 
identifier  list) 

default  glyph  identifier  (the  identifier  of  a  default  glyph 
that  is  used  for  unspecified  code  points) 


Items  for  Data  Record: 


number  of  glyphs 

(I) 

code  bytes 

(I) 

code  list 

list 

of 

(S) 

glyph  identifier 

list 

list 

of 

(S) 

designation  tail 

sequence 

(S) 

glyph  collection 

identifier 

S 

default  glyph  identifier 

S 

Data  Record  Description: 

The  parameters  define  a  glyph  collection  and  associate  each 
glyph  in  the  collection  with  a  code. 
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2}  CGM  Sncodlsgs  (reference  ISO  8632  CGM;  Parts  2#  3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items), 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for.  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4 .  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binairy  integers. 

3)  GKS  Functional  Specification  (reference  ISO  7492,  GKS 
Functional  Specification) 

The  proposer  only  wishes  to  use  this  escape  with  the  CGM  standard. 

4)  GKS  FORTRAN  language  binding  (reference  ISO/IEC  8651-1,  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

The  proposer  only  wishes  to  use  this  escape  with  the  CGM  standard. 

5)  GKS  Pascal  language  binding  (reference:  ISO/IEC  8651-2, 

GKS  Language  Bindings;  Part  2:  Pascal) 

The  proposer  only  wishes  to  use  this  escape  with  the  CGM  standard. 

6)  GKS  Ada  language  binding  (reference  ISO/IEC  8651-3,  GKS 
Language  Bindings;  Part  3: Ada) 

The  proposer  only  wishes  to  use  this  escape  with  the  CGM  standard. 
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ProDoaat  Number: 


Data  of  Presentation:  I  6  October  1989 


Soonsorina  Authority:  I  ANSI 


Class  of  Graphical  Item:  I  ESCAPE 


Specific  Escape  I  Function  Identifier:  |  Select  General  Fill 


Description 


This  escape  function  selects  a  general  All  interior  style  for  filled  area  primitives.  It  is  only  applicable  to  the  CGM 
standard.  The  filled  area  treatment  in  this  case  is  derived  by  copying  the  indicated  segment,  repeated  as 
necessary,  throughout  the  filled  area.  The  current  Fill  Reference  Point  and  Pattern  Size  are  used  to  locate  the 
segment  and  modify  its  size.  The  interior  style  reverts  back  to  one  of  the  defined  interior  styles  when  the  next 
Intaroir  Style  element  is  encountered. 


Additional  Comments 


Justification 


Inclusion 
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Description: 

Select:  General  Fill  selects  interior  style  "general  fill"  based 
on  the  segment  Identified  by  segment  identifier  as  defining  the 
general  fill.  This  escape  is  only  applicable  to  the  CGM  standard. 
This  segment  is  copied  within  subsequent  filled  areas  as  many  times 
as  needed  to  fill  them  completely.  This  copying  takes  place 
according  to  the  following  rules: 

1)  The  graphical  effect  is  as  if  successive  COPY  SEGMENT  Elements 
were  encountered  with: 

a)  the  initial  translation  portion  of  the  copy  transformation 
matrix  translates  to  the  current  Fill  Reference  point; 

b)  subsequent  translations  are  derived  by  calculating  the  extent  of 
the  virtual  device  coordinates  present  in  the  segment,  and 
offsetting  the  translation  point  to  "repeat"  the  segment  as 
necessary  until  the  area  is  completely  filled; 

c)  the  scaling  and  rotation  portion  of  the  copy  transformation 
matrix  is  derived  from  the  current  Pattern  Size;  no  rotation  is 
done,  and  the  pattern  height  and  pattern  width  components  define 
the  vertical  and  horizontal  scaling  respectively; 

2)  All  graphical  objects  are  clipped  to  the  boundary  of  the  filled 
area  primitive. 

If  the  segment  identifier  is  not  a  valid  segment  name,  then  to 
current  interior  style  shall  remain  unchanged.  The  interior  style 
reverts  to  one  of  the  interior  styles  defined  ^n  the  CGM  standard 
when  the  next  valid  INTERIOR  STYLE  element  is  encountered. 
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Relationship  »,o  _ ataxidarda  ; 

1)  C6M  Fiinctional  Specification  (reference  ISO  8632  CGM; 

Part  1:  F\inctional  Description) 

A  functional  description  of  the  Select  General  Fill  escape 
parameters  is : 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D)  : 

segment  indicator  (the  neune  of  a  segment  used  as  the  fill) 

Items  for  Data  Record: 

segment  indicator  (SN) 


Data  Record  Description: 

The  parameter  gives  the  name  of  the  segment  to  be  used  as  a 
"general  fill". 

2)  CGM  encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 

3)  GKS  Functional  Specification  (reference  ISO  7492,  GKS 
Functional  Specification) 

The  proposer  only  wishes  to  use  this  escape  with  the  CGM  standard. 

4)  GKS  FORTRAN  language  binding  (reference  ISO/IEC  8651-1,  GKS 
Language  Bindings ;  Part  1 :  FORTRAN) 

The  proposer  only  wishes  to  use  this  escape  with  the  CGM  standard. 
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5}  GICS  Pascal  languaga  binding  (reference:  ISO/IEC  8651-2/ 

6KS  Language  Bindings;  Part  2:  Pascal) 

The  proposer  only  wishes  to  use  this  escape  with  the  CGM  standard. 

6)  6KS  Ada  language  binding  (reference  ISO/IEC  8651-3,  GKS 
Language  Bindings;  Part  3: Ada) 

The  proposer  only  wishes  to  use  this  escape  with  the  CGM  standard. 
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